Script

Introduction

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"[3] 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:

1. Remove bugs to improve product quality, AKA health and hygiene improvements.
2. Close security holes.
3. Improve usability.
4. Remove performance bottlenecks.

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.

Why bother?

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[4] 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.

Removing bugs (the .0.1 release)

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.

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 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.

Improving usability (the .0.3 release)

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.

Remove performance bottlenecks (the .0.4 release)

According to Donald Knuth:

"premature optimization is the root of all evil" [2]

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.

Conclusion

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.

Wrap-up:

Lets recap what we have covered today:

1. After a major new release, it is important to make a few subsequent patch releases to consolidate overall product quality.
2. Those patches should address bugs, security holes, usability, and performance issues.
3. Semantic versioning, or semver for short, is used to determine appropriate version numbers for major versions, minor versions, and patches. See the website https://semver.org/ for details.
4. A Jenga tower is a good visual metaphor for software development: the new blocks added to the top of the tower represent product features, while the blocks at the base represent technical debt. If the team neglect the base for too long while continuing to build on top, the whole tower will become unstable. Release consolidation represents the strengthening of the base of the tower.
5. You need to ensure that your release processes can support frequent and easy patch releases to production, and your team are confident in doing that.
6. For your first patch release after a major release, the .0.1 release, you should focus on fixing bugs that are identified in production after the release.
7. While we all aim to capture our bugs in pre-production, the reality is that some will still make it to post-production: this is just a fact of life when developing software. Identify the root cause, fix, then deploy the patch with no drama.
8. For the second patch release, .0.2, the team should focus on security fixes. That can include fixes unique to your product, or version bumps on 3rd-party dependencies to ensure that you are availing of ongoing security fixes from them.
9. For the third patch release, .0.3, the team should focus on improving the User Experience (or UX) based upon feedback from the users of the current release. Small tweaks to the front end, like adding a button or changing some colours to make an important element stand out more, can make a big difference to the quality of life of your end-users.
10. Finally for the fourth patch, .0.4, the team should focus on fixing performance bottlenecks that they have identified via logs and monitoring, before they become bad enough that end users start to notice.
11. 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.
12. Software quality can compound over time, but only if we put in the regular effort to ensure it.

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!

References

[1] : My original 2012 blog post on "Consolidating a dot zero release" - https://techleader.pro/a/369-Consolidating-a-dot-zero-release

[2] : "Program optimization" - https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize

[3] : Semver - https://semver.org/

[4] : Jenga - https://en.wikipedia.org/wiki/Jenga

Download

techleaderpro-episode-19.mp3

File details: 17.9 MB MP3, 12 mins 24 secs duration.

Title music is "Still Cold" by Crystal Shards, licensed via www.epidemicsound.com

Subscribe

Apple Podcasts (iTunes)

Spotify

Google Podcasts

Amazon Music

Main RSS feed

Sponsor

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!