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.

Main article: Roadmap

The midPoint development cycle has mostly stabilized on two releases per year plan used by many other open source products. Spring release (approx. March-May) and Autumn release (approx. September-November) are expected every year. Out current vision about roadmap is documented but this has to be understood only as a rough plan, an approximation. The roadmap is ultimately demand-driven. MidPoint users are bringing ideas and asking for features all the time and this significantly influences the roadmap. A feature that is frequently demanded by the users has a better chance to get into a roadmap and it will get planned to be developed soon. Less popular features are planned for later dates.

Anyone can influence the roadmap by requesting a feature. The preferable way to do this is to use the mailing lists to discuss that feature. We prefer public conversation because it allows more people to bring in ideas and the requested feature can take a better shape. Once discussed the feature will be added to the roadmap. However, please keep in mind that there is an obligation in requesting a feature. We will expect that the one who requests a feature will help with testing the feature once it is developed (see Bugfixing and Support page).

Main article: Bugfixing and Support

TODO

TODO: logging

api,spi,impl,test packages

TODO: point to example component

TODO: premature optimizations, readability, simplicity.
Iterative/incremental: Make it work, then improve.