Large-scale software projects, such as the Linux Kernel or Chrome, have dedicated release engineers. Their job is to balance the software quality and feature set of a release while upholding the release schedule. The release process often involves a stabilization period in which development teams are not allowed to introduce new features. The stabilization period involves changes to the software, such as bug fixes. For Linux and Chrome, these amount to roughly 9 – 15 % of the effort required to implement new features.^[2]

Release stabilization is a temporary measure Such a stabilization period lasts a couple of weeks and can increase the quality of a software significantly, but it's only temporary. It lasts only as long as new features are introduced into the system or existing functionality needs to be adapted. The idea to stabilize a software component permanently without changes to the code is a fallacy. As in my previous article on the importance of software maintenance, I will base my argument on Lehman's laws of program evolution which summarize 30 years of his research.

The business and its employed software systems influence each other

VIII. Feedback System
[Software] evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.

— Lehman et al. (1997) - Metrics and Laws of Software Evolution - The Nineties View

What is formalized as a universal law essentially means that the business and the software used by it influence each other. If we don't acknowledge the fact that software needs to be adjusted to changing user needs and business objectives, the software will become obsolete and turn from an asset into a liability.

Software can only be stable within a specific context A stabilization can only be performed within the context of the current user needs and business objectives. It is only temporary.^[3] That means the software inevitably has to adjust, too. If parts of the system are under a “stabilization lockdown”, they cannot be evolved to meet the changing surroundings.

Long-term stabilization requires automation and automated testing Rather than locking down specific systems or components I recommend a long-term stabilization effort that is not geared towards process automation and automated testing. These will lead to a more reliable development process, and to a shorter feedback loop, respectively. Errors that were introduced due to necessary adaptions of a component can be caught before they affect end users.

---

1. I acknowledge it's possible to get programs to a state where they are effectively stable and remain so for years to come. Some examples are basic tools like grep or cat. Note that these programs are universal and do not contain any business logic. The remainder of this article will only concern itself with software that is written in the context of a business process. ↩︎

2. Rahman, Rigby (2015) - Release Stabilization on Linux and Chrome (opens new window) ↩︎

3. Mendoza, Carroll, Stern (2010) - Software Appropriation Over Time: From Adoption to Stabilization and Beyond (opens new window) ↩︎