Introduction

When we release a dot zero version of a web application (1.0....X.0), the incrementation of the major part of the version number normally indicates that we have added some major new features. In an ideal World, these new features will have been thoroughly tested to ensure that they do not contain any bugs before the release date, however in reality we can never be 100% sure that bugs or other issues are not present.

So what do we do next? Well, many projects continue in "project mode": adding any remaining features that did not make the cut for the dot zero release, while simultaneously fire fighting any major production issues that arise post go-live. In this article, I will explore why this is a bad idea, and why you should instead consolidate your existing application to:

1. Remove bugs.
2. Close security holes.
3. Improve usability.
4. Remove performance bottlenecks.

Each of these patch releases should occur after each dot zero release (or any release that adds a significant amount of new features), in the order outlined above. I will explain my reasoning for this later, but first let us look at why consolidating your release is a good idea.

Why bother?

If you continue to add new features to your application while ignoring issues with the core of the system (bugs, security holes, usability issues, or performance bottlenecks), you are building a Jenga tower. The holes at the base of the system become more pronounced, as the weight of new functionality adds additional strain on them. Best case scenario, you have an unstable application. Worst case, it collapses.

This pattern is quite common when project teams are only focused on the top of the tower (i.e. the new features), but as anyone who has played Jenga knows, the real action is at the base. A few quality-focused releases of you application will help to consolidate the base.

Removing bugs (the .0.1 release)

Software development is complex, and with complexity comes bugs. You can reduce the impact of bugs in your project by using various automated testing tools and carrying out manual testing, but you will still have bugs. After go-live, you should focus on fixing your bugs next.

Real end users will always use your application in ways that you did not expect, causing bugs to manifest. In addition, bugs can occur in production server environments that did not occur in the development environment, due to configuration or deployment issues. All of these teething issue should be tackled upfront, especially the glaring ones that directly affect end users.

Closing security holes (the .0.2 release)

With each additional feature that is added to an application, a new potential attack vector is also added. Security penetration testing: passive monitoring and invasive testing, should be carried out after work has stopped on bug fixing, because in fixing a feature bug you may have just introduce a new security hole.

Improving usability (the .0.3 release)

User Experience (UX) is vital to the success of a software project. If an application is awkward to use or counter-intuitive, you will lose users (or have unhappy ones if they are a captive audience). Over time, users will give feedback about the application either directly or via usage analytics study by you, which you should then back-feed into a release that improves the UX and User Interface (UI).

The aim here is not to completely overhaul the UX and UI, remember we are talking about patch releases, but to incorporate user feedback into UX and UI tweaks as soon as possible.

Remove performance bottlenecks (the .0.4 release)

According to Donald Knuth:

"premature optimization is the root of all evil"

In keeping with that wisdom, we are keeping the optimization patches until last. Your server logs and analytic packages should help you to identify CPU, memory, network I/O, and disc I/O bottlenecks in your application. From there, you can go about making the necessary code or platform tweaks that will enable you web application to support more users on the same hardware.

Conclusion

Commercial pressures normally dictate release cycles, not software development best practices. This is a sad reality, as we often end up with Jenga towers that nobody is happy with. As professional software developers, it is our job to push for software development best practices in our organizations, even in the face of resistance.

The fictional consolidation release cycle outlined above is meant to act as a template only, in reality you many not be able to implement any these on your commercial projects: but understanding and communicating the consequences of not doing some consolidation releases may act as a powerful motivator.

Credits

Jenga tower image from Wikipedia

---

Updated 2022 : note that the above post was originally published in 2012, but is left here for archival purposes.