Techniques to improve quality by limiting the number of changes late in a release cycle. Plus sausages, Mercedes-es, and a lesson in Computer Science from the Sweet Science. Let’s get ready to rumble!

In the final analysis, the quality of your software is really the quality of your software releases. The testing and bugfixing in between, all the wailing and gnashing of teeth, your end user cares nothing about.

How, then, to ensure your releases are bug-free ?

From one perspective, there is a direct, inverse relationship between the amount of new features introduced in a release, and the amount of quality. The more features you try to pack in, the lower the quality. There are additional factors to consider, of course, but it’s more significant than you might think.

Das ist mir wurst

The automaker Mercedes-Benz has (had?) a reputation for unmatched quality, built up through the 1960s, 70s and 80s. But in building this reputation, they tended to adopt new engine technology rather slowly. For each new model “release”, they kept the new feature set relatively low, so to speak. For example Mercedes was a late adopter of electronic fuel injection. They tried an early model, it was “buggy” so to speak, so they stuck with mechanical systems while Ford and Chevy EFI’ed ahead.

Of course in software, falling behind can be just as deadly as a buggy product. It’s a tricky balance, one that many businesses fail to get right, with disastrous consequences.

It’s helpful, though, to understand the importance of when we introduce features within a cycle. And there’s an array of techniques we can leverage along the way to improve quality and mitigate risk.

Peaking at the right time

In the world of professional boxing, a fighter enters an intensive “training camp” about three months before a scheduled bout. Rigorous workouts, technique, nutrition, and sparring with top competitors, all focus towards the goal of one night of top athletic performance.

During this training camp, a chief concern is when will the fighter “peak” in their athletic output. If they go all out right up to the end, come fight night he (or she) will be listless, drained and ineffective. There’s a critical resting period, usually 5-7 days out.

Now we could say that in a release cycle, our final QA is like the recuperation period before the fight. We let our release branch “rest”, as it were. No commits except for bug fixes.

Developers should cut to separate branches. If there’s an extended testing cycle, features can be integrated into a shared branch, and automated testing can target this intermediate branch.

When the customer needs it now

Naturally, customers are going to be impatient and want new features introduced now, release cycle be damned. Should you push back and refuse customer requests ? Should you add the features, disrupt the release code and compromise quality ?

One option is to offer customers an early release preview from a different branch. You’ll need to be adept at managing multiple deployment environments, making sure servers, code and databases are in sync with the preview, and not interfering with your stable release. A strong investment in Devops infrastructure can be a big help here.

Collaboration > Argument

Your “preview” code – immature work requirements, incomplete implementation, and technical mistakes and misunderstandings – this is a recipe for lots of bugs. Make sure to manage your customers’ expectations !

Done properly however, these sneak peeks can greatly improve your customer relationships:

  • Customers see more of the work that you’re putting in on their behalf.
  • Pick some favorites from the customer’s wish list and offer a sneak peek (there will be bugs!)
  • Customers eager to see new functionality will quickly find + report new bugs. Ie., free QA!
  • As customers report bugs and see a quick turnaround, you’re building a feeling of “teamwork”. Ie, customer retention !

Using bugs to increase customer loyalty – what a concept !

Manage branches, manage expectations, and a build a strong Beta pipeline that improves customer relationships and quality while keeping last minute requests off your stable release branch. Key ingredients to software success !

Happy testing !