|Published on 2022-12-14 by John Collins.|
When we release a dot zero version of an application, for example 1.0 or 2.0, the incrementation of the first part of the version number indicates that we have added some major new features. This is a common convention in the software engineering world, known as "semantic versioning" or "semver" for short.
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 should the development team do after this major release?
Well, many development projects continue in "project mode": by adding new features from the product roadmap 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 podcast, I will explore why this is a bad idea, and why your team should instead consolidate your existing application code base to:
Each of these represents a patch release, that should occur after each major dot zero release, or indeed any release that adds a significant amount of new features.
The order above is deliberate, and that sequence will become clear as we go through each one. But first let us look at why consolidating your release is a good idea in the first place.
If you continue to add new features to your application while ignoring issues with the core of the system (including bugs, security holes, usability issues, or performance bottlenecks), you are building a Jenga tower.
Just like a real Jenga tower, the weaknesses at the base of the system become more strained over time, as the weight of new functionality adds additional strain on them. In the best case scenario, you have an unstable application. In the worst case, it collapses.
This pattern is quite common when project teams are only focused on the top of the tower (i.e. implementing new features from the product roadmap), 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 and strengthen those foundations.
Software development is complex, and with such complexity comes bugs. Bugs are a normal side affect of software development, especially when you have just developed a group of new complex features: there will be edge cases that inevitably your users will find that your QA team misses.
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, it is just a fact of life. 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 issues should be tackled upfront, especially the glaring ones that directly affect end users.
Production patch releases are your friend, so make sure your release processes can support frequent and easy patching of your production environment.
With each additional feature that is added to an application, a new potential attack vector is also added. Security testing including passive monitoring and penetration 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.
An automated security scanner can also be run during your CI/CD build processes, to pick up the known issues automatically so you can plan to fix them now. Such scanners will version-check your dependencies, and flag versions that have known issues requiring an upgrade.
In general, security vulnerabilities are not identified as frequently as regular functional bugs, but I still like to have a focus on security during the .0.2 release, to take care of business as usual version bumps on dependencies like Linux RPMs, containers, or libraries that typically include security vulnerability fixes from third parties.
User Experience, or UX for short, is vital to the success of a software product. 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 analysis studies by you, which you should then feed back into a new 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.
User feedback is golden, and that feedback should always be used to improve your product iteratively.
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 your application to support more users on the same hardware.
When we ignore performance, it tends to degrade overtime. Rather than waiting until it becomes noticeable by end users, it is better to fix performance bottlenecks as soon as they are identified by engineering, and do so in small iterations via patching.
Commercial pressures normally dictate release cycles, not software engineering best practices. This is a sad reality, as we often end up with Jenga towers that nobody is happy with. As professional software engineers, it is our job to push for software development best practices in our organizations, even in the face of resistance.
When we build a fortress, it's over-engineered for most scenarios, but a Jenga tower is badly under-engineered. Like with most things in life, we must strike a balance, and tension between both extremes is healthy.
The idealised consolidation release cycle outlined here in this episode is meant to act as a template only, in reality you may not be able to implement all of these on your commercial projects: but understanding and communicating the consequences of not doing some consolidation releases may act as a powerful motivator.
Software quality can compound over time, but only if we put in the regular effort to ensure it.
Lets recap what we have covered today:
I hope you enjoyed this episode, and I look forward to covering the next topic in this series with you! In the interim if you want to follow me online, you can find my blog at TechLeader.pro, or follow me on Twitter @TechLeaderPro.
Thanks for your time, take care and have a great week!
 : My original 2012 blog post on "Consolidating a dot zero release" - https://techleader.pro/a/369-Consolidating-a-dot-zero-release
 : "Program optimization" - https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
 : Semver - https://semver.org/
 : Jenga - https://en.wikipedia.org/wiki/Jenga
File details: 17.9 MB MP3, 12 mins 24 secs duration.
Title music is "Still Cold" by Crystal Shards, licensed via www.epidemicsound.com
Five.Today is a highly-secure personal productivity application designed to help you to manage your priorities more effectively, by focusing on your five most important tasks you need to achieve each day.
Our goal is to help you to keep track of all your tasks, notes and journals in one beautifully simple place, which is highly secure via end-to-end encryption. Visit the URL Five.Today to sign up for free!