The Case for Releasing Early and Releasing Often

Major software systems can be intimidating to release to the public, perhaps due to the potentially complex nature of a software release. One pitfall I have noted during my career is that people can fall into the trap of releasing too much functionality at one time. Larger releases of software generally leads to a complex release and a release process that is not frequently followed. This release process is generally not refined due to the infrequency of it being followed. In order to counteract that I recommend the Release Early, Release Often (RERO)¹ software development philosophy.

A larger set of functionality released at once makes the impact of a failed deployment much greater: rollback becomes more difficult and if rollback has to occur, then it is likely everything is rolled back ². Contrast this to the scenario of rolling out a single feature: if that fails, then you only have to rollback that feature. The impact of having to roll back several features is less than that of rolling back several.

An unrefined software release process is expensive and potentially misunderstood. The more frequently a release can be done, then the tighter a release process can become. Tightening up the release process with each release also makes servicing the application at a future date more accessible to other developers. New developers can release bug fixes and functionality upgrades with less resistance. This makes maintenance cheaper and also helps to ensure that the knowledge of releasing the software is not tied to a group of system experts (e.g. original developers). Decoupling system experts from the release means they are free to add value elsewhere instead of managing releases. In the scenario that they leave ³, then they are taking less tacit knowledge with them.

If you are considering building a software system, then you should also consider baking modularity into the architecture. It is likely that this will likely increase the cost of individual features by some margin due to the software developers needing to create sensible interfaces between modules. This cost will enable RERO and with that, will enable a tighter feedback loop between your business and the software users. Enabling feedback earlier can help prioritise the next functionalities to be developed. Further to this, a modular system becomes easier to test: only updated modules need to be released and tested. Also consider RERO as a way to enable market testing, instead of developing a full feature set and releasing with a “big bang” approach, your business has been given an opt-out opportunity. Further development can be ceased⁴ if the important features are released earlier and do not have the expected user uptake.

Where possible, you should strive to release the simplest version of a software system you can have. Follow the RERO philosophy. Larger releases carry higher risk and higher stresses. Any failure in a release has a higher potential loss. A failed release may also carry deadline slippage with it: a second, complex release will be carried out along with a higher testing effort (due to change complexity). Any last minute code fixes introduced in a re-release may also be of questionable quality due to being implemented under stressful conditions.