How we work

We are a team of web application developers based in Warsaw and Tarnow, Poland, cooperating closely with Brickwork Ventures in Winterthur, Switzerland which provides Business Analysis, Management and Advisory Services to our projects. In our work we put the biggest emphasis on communication, always keeping our customers up-to-date. We believe in the value of trust, honesty and openness. We will tell you what we can do, and also what we cannot do. We try to be available to our customers 24/7 communicating mostly over Skype and email but if possible we strive to maintain personal contact too. When most IT companies concentrate purely on implementation of the project we believe that it’s impossible to deliver high quality software without thorough analysis and testing.

In short, our philosophy is based on the following pillars:
  • Communication is key: Many misunderstandings can be avoided if they are discovered early on. The only way to find out is to talk to people.
  • Poor analysis and lack of technical expertise are the main reason for failure, cost overruns and frustration in IT projects. Make sure that short-term solutions do not become long-term problems.
  • High quality work comes from motivated people, and motivated people require values and a passion for the product. A lean group of talented experts will outperform a larger group of mediocre workers.
  • Test, test, test. It will really make your life easier!

Business Analysis

Business Analysis is about shaping out a concrete solution from abstract ideas and objectives that different stakeholders usually have in a project. The way to go from high-level objectives to concrete solutions is to understand objectives and their background: Where are they coming from – what concrete solutions would be acceptable to what stakeholders? Which options do we have at all and what impact will they have on technical feasibility, risks, costs and time? The way to capture, organize and visualize those thoughts and expectations is to write the concepts out.

We typically write a high-level concept right at the start of the project: It establishes the big picture. At first, it is mainly a communication tool and it helps develop a thorough understanding of the problem. It is much cheaper to come across a nasty little (or even bigger) snag or trap during the conceptual phase than during implementation.

Shortly after developing the high-level concept, we start with data modelling. If you mess up the data model, you mess up the project. Don’t forget that we are building information systems: whatever happens in the system will be reflected in the data; the structure of the data represents our conception of the outside world. If this conception is incomplete, contradictory or fuzzy, then you will not be able to build a proper database model. If this is the case, it is better to think over it again before starting. Sort this out at the beginning.

We know we cannot predict the future and therefore it is impossible to cater to every possible requirement or circumstance that may potentially be relevant at some point down the road. Nonetheless it is crucial to assess whether a specific design will be able to support the most likely scenarios and developments in the near and mid-term future. We make sure that short-term solutions don’t become long-term problems.


Methodology and Processes are tools to support the project – not the other way around! We favour lean processes to avoid bureaucracy. Many projects eat up considerable amounts of time to please all kinds of formal requirements: reports, risk logs etc. Of course they have to be done, especially in complex organisational settings, and we do them if required. However, our philosophy is: less is more. Formalities should support the project and the project should never support the formalities.

We tend to use a project development methodology called Agile ( A project is organized into weekly updates called ‘iterations’. On a weekly basis, we plan which features and bugs should be implemented and fixed during the next phase. While the development team is implementing and fixing, the business analysts specify new features. Typically, we know one or two weeks in advance which feature should go into implementation next, so these are prioritized. Agile development demands that at any given time there is a working version of the system available. In the beginning, the system may not yet do a lot but as it evolves, it always reflects the current state of the application and can be reviewed and tested by analysts and users.

We communicate, with customers and internally, as often as possible. Misunderstandings can be avoided if they are discovered early on. Answering a question about a particular requirement doesn't take more time than drinking a cup of coffee but it’s really better to invest 5 minutes and progress with development smoothly than to rewrite wrongly implemented functionality which often takes days. Communication technologies currently available are great – but you have to know people. Yes, we use Skype (and web-based communication in general) and we love it, but we regularly meet in person to discuss things face to face and to have a beer (or mineral water, if you like) together.


We are focused on particular technologies and tools. This allows us to be experts in what we do and possess in-depth knowledge of how things work, what they are meant for, what can be achieved with them and also what they should not be used for. «If the only tool you have is a hammer, then every problem looks like a nail» - well, we have many tools for different problems. Importantly, our tools are well recognized technologies with established communities of users and usually they are open source. We create object-oriented business web applications. Our team has mastered Seam2 and 3 as well as CDI, lightweight dependency injection containers, which form the core of our solutions. Years of experience with those frameworks allows us to actively contribute to the community. Nowadays, applications are usually not stand-alone and we therefore make them easy to integrate with other systems. For that purpose, we employ such enterprise standards as JMS for messaging and WebServices (both RestEasy or JBossWS).

Everyone wants fast and elegant applications but IT Crowd looks out for maintainability. For business applications we leverage Java Server Faces, a very well designed framework that speeds up such common tasks as data validation, conversion, navigation, etc. Thanks to its component-based approach and component-event modelling our developers can focus on business problems. Together with large sets of common components from JSF standard libraries we use beautiful Ajax aware components from RichFaces library. Thanks to those libraries our applications have a consistent look and feel 'out of the box' and are easily skinable. Sometimes, when need arises, we dive easily into pure HTML, CSS and JavaScript powered by frameworks like jQuery, Prototype or Angular. On the presentation layer, our team has made large contributions to the open-source community, especially by bringing some great jQuery plugins to JSF. You can consider us experts in JSF component development, especially based on RichFaces CDK.

The software we create, as well as every business application, is backed by well-established database management systems. Thanks to ORM standards and frameworks like JPA and Hibernate, our solutions are not dependent on a particular vendor. Our applications are easily portable to Oracle, MySQL, H2SQL, Derby or – our favourite – PostgreSQL. When there is a need to archive data in a database then we use Hibernate Envers, which takes all the burden off the developers shoulders and seamlessly integrates with Hibernate core. We are also aware of such security requirements as encrypting sensitive data in the database. For that purpose we use Jasypt.

Testing & Quality

There is no quality without testing. Manual testing, which is a must for acceptance testing, is not sufficient. It is very expensive, thus tests must be automated. We test software on several layers. Unit tests are used for small blocks of code testing. But testing single classes is not enough, especially if it heavily depends on resources injected by a container. Testing applications in a mock-up environment always leaves doors open to bugs that appear only in the real environment. Our integration tests use Arquillian to run tests within a container to eliminate this problem. For this technology our team has made contributions to the community that has received positive feedback and applause. Besides unit and integration tests that cover system internals we write user interface tests using such tools as JSFUnit, HtmlUnit, Warp, Graphene or Selenium.

We enforce coding conventions to ensure that our code is clear, readable and maintainable. Some tools that have helped us achieve those goals are Checkstyle, PMD and Findbugs. Most QA processes are automated by leveraging Jenkins continuous integration server which runs tests and QA checks after every commitment.