Our development process is evolutionary, not revolutionary. We follow iterative and incremental software development process. We proceed is small steps, from a working software to a working software. After deploying a result of each step we learn what needs to be improved and we improve it - either by adding a new feature, by fixing existing problems or by reworking part of the system. Experience clearly shows that an appropriate mix of adding new code, refactoring existing code and removing dead code is needed in each step to make the software development process sustainable.

Development of our software is guided by product architecture, but the architecture is in turn guided by the development and deployment of software. This may sound confusing but it makes perfect sense in the iterative process. The architecture is set at the beginning then a development starts. The development may uncover that some of the parts of the architecture are wrong, therefore they must be fixed. The deployment may uncover that the whole product direction needs adjustment, so it has to be adjusted. The final product is the ultimate indicator of how "good" the architecture is.

We use a rethink and evolve approach to govern the development process. We consider the architecture to be an ultimate "vision" for the product. A guideline that the developers use when making a design decisions. Whenever a problem or a missing feature is found, the solution is reflected to the architecture. But that does not necessarily mean that also the code is immediately fixed. There may be many reasons why not to do that right away. Firstly, the fix may be quite time consuming or may depend on things that are not yet done. Secondly, we may be unsure about the quality of the solution and it may need more time to "settle down" (e.g. increase our confidence by public review or prototyping). Thirdly, the problem may have neglectible consequences and there may be higher priorities to attend at the moment. By placing the solution to the architecture the problem won't be forgotten and the development team will slowly and naturally incorporate the solution into the code.