Dr Bloodmoney, or How We Got Along After Waterfall

Dr Bloodmoney, or How We Got Along After Waterfall

March 03, 2020

DevOps + Quality Engineering (QE)

Establishing a QE-focused DevOps practice might just be the single most important thing your organisation can do to build sustainable competitive advantage.

If you’re wondering what I’m talking about, please allow me a quick recap.

Most people with even a tenuous connection to the world of software development have some understanding of DevOps. As you probably know, DevOps has evolved to overcome the myriad of problems associated with the traditional waterfall-based approach to software development, where at least three separate teams (Development, Quality Assurance and Operations) slow down, make a mess of and unnecessarily complicate the software development lifecycle (SDLC).


In the world of Waterfall software development, old-school Quality Assurance (QA) works OK. The problem is that it just doesn’t scale. As software complexity has increased, QA teams have failed to keep up. The typical response is to either reduce the tests that you run (no-one likes testing cycles that take more than a month) and/or engage an offshore testing company and send your testing overseas. You can then throw dozens of manual software testers at the problem for little cost. Or so it first appears.

Waterfall software development practices stink. This approach:

  1. dramatically slows down the release cycle (in the enterprise, a quarterly release cycle is still pretty much standard);
  2. increases your costs (the more time it takes to uncover bugs and problems the more expensive they are to fix);
  3. causes significant quality problems (the chance of significant defects making it into production remains), and;
  4. results in a very high failure rate – largely due to bug-infested, low quality software.


Then along came Agile principles and methodologies, which prioritise fast feedback. That feedback almost universally indicated that running testing after development slows everything down terribly, while chucking the “finished” software over the wall to the Operations team at the end creates a whole host of new and interesting problems.

It became very clear that a different approach was needed.


DevOps has become extremely popular in organisations as they adopt Agile principles. In organisations practicing DevOps, barriers to do with org structure and culture are broken down and cross-functional teams are created to bring business, development, testing, operations (and even security) responsibilities together. DevOps teams are obsessed with automating everything they can. They can move much faster, don’t point fingers and have accountability for business outcomes.

Teams practicing DevOps:

  1. can release new code into production in minutes rather than months;
  2. are far more efficient, cost effective, productive and happy, and;
  3. produce higher quality software (releasing code frequently, in smaller increments that is run through an automated pipeline of tests dramatically reduces the likelihood of defects reaching production).


A key characteristic of DevOps is that every time a new software build is complete, a suite of tests is run automatically to minimise the risks of things breaking. However, a common concern of organisations considering a move to DevOps is that rather than reducing the likelihood of defects reaching production, the increased release velocity (thanks to the use of Continuous Delivery platforms and pipelines) will actually result in more defects and greater stability problems.

Which brings me to the discipline of Quality Engineering.

Quality Engineering (QE)

The shift from Waterfall to Agile to DevOps has resulted in organisations taking an entirely new approach to Quality. Quality Assurance – something that happens after development, gave way to building a suite of automated tests to speed things up. The more mature an organisation’s DevOps practices are, the more they have taken this ‘test early, test often’ strategy to the next level – which has given birth to the discipline of Quality Engineering. QE is an approach that embeds quality into the SDLC even before the very first line of code is written.

Quality Engineering goes far beyond simply automating your testing. When you have a DevOps team practising QE, quality permeates everything the team thinks and does, and becomes the beating heart of each stage of the SDLC.

Take Test-Driven Development (TDD) – a software development approach that writes unit-level tests before the code is developed – providing the earliest possible feedback so your devs can re-factor quickly. Another popular approach is Behaviour-Driven Development (BDD) – which focuses on the expected business outcomes, and the reframing of your testing as descriptions of behaviour. BDD can be built around the Agile User Story itself:

Feature: (High level software feature)

Given (the initial context)

When (describes an event)”

Then (an expected outcome)”

While it looks and reads like English, it is actually a grammar that can be transformed into code.

When you adopt a Quality Engineering approach, you maximise test coverage for your applications across multiple dimensions – functionality, accessibility, usability, security, performance and reliability. And this goes beyond simply your development and testing practices; it influences the decisions you make when you’re designing the architecture of your application all the way through to how your test and production environments are built and managed.

QE complements both Agile and DevOps development practices and processes by ensuring that the outcomes from every stage of the SDLC are congruent with your business objectives.

DevOps + Quality Engineering – the holy grail?

QE is concerned with building quality into every part of the SDLC – from the moment an application is conceived of and designed, all the way through to its delivery into production. When you build a DevOps CI/CD pipeline through the lens of QE, your software is both built and tested simultaneously at every stage – resulting in appropriately awesome outcomes!

The world of business and your ability to create value for your customers is today intrinsically linked to your ability to manage the SDLC effectively. Software forms one of the most critical customer touchpoints for many organisations; and practically every business relies on it to scale and streamline your operations. Your competitive advantage is closely linked to how quickly, effectively and safely you can release new code into production.

By adopting DevOps + QE, your organisation will be on its way to creating sustainable competitive advantage – no matter what industry you’re in.

And what does all this have to do with the Dr Bloodmoney reference in the title?

Dr. Bloodmoney, or How We Got Along After the Bomb was post-apocalyptic book written by Philip K Dick in 1963, a year in which he essentially sat in his garden shed hammering at his typewriter and consuming industrial quantities of amphetamines (some time before his psychotic breakdown). One of the characters – Walt Dangerfield – is an astronaut who has been left stranded in orbit, and who broadcasts lonely messages to the world below. His very presence provides humankind with hope for a better tomorrow. It’s a stretch I’ll admit, but for all those toiling away in enterprises still battling their way through a quarterly release cycle – a better tomorrow is around the corner!

If you’d like to know more, send us a quick note – we’re always up for a coffee and a chat. We love nothing more than to help our customers become the envy of all those in their industries!