The Second Law of Software Delivery

Why the single plan everyone signed off never had a chance — and what actually holds delivery together

This drift is not a failure of discipline. It is entropy: the tendency of any ordered system to slide towards disorder unless energy is continuously put back in. Therefore, the quality of your ultimate delivery when viewed against the plan is congruent on the amount of effort you put in to fight that drift.  The single agreed path was never going to hold on its own, and the job of everyone downstream of the plan is less to follow it than to keep noticing where reality has pulled away from it.

The plan describes how the work is imagined. The product reflects how the work is actually done. The gap between the two is not a risk you might eliminate with tighter project management – it is a property you have to design around.

A tended garden, left alone, becomes a wilderness

A garden makes the point better than a textbook. Designed, planted and pruned, it is a small triumph of order over its surroundings. Leave it a single season and nature reclaims it – not out of malice, but out of sheer tendency. Weeds do not need a plan. Order does.

This is not a metaphor imported from physics and forced onto software. Software has its own version of it, observed and documented long before the current debate. Manny Lehman’s laws of software evolution, drawn from studying real systems in the 1970s, held that a system’s complexity increases as it evolves unless deliberate work is done to reduce it – a pull Lehman himself described as an analogue of the second law of thermodynamics. A delivery plan is that garden on the day it is finished: at its most manicured, its most complete, its most persuasive. Sign-off is peak order. From there, the only real question is how much energy you are willing to spend keeping the design legible as the season runs on.

Every handoff is a translation, and translation loses

Software is not built at a single point. It is assembled across a chain of hands, and every link in that chain is a translation.

Requirements capture someone’s intent – imperfectly, because intent is slippery and language is lossy. Architecture interprets those requirements into structure. Developers interpret the architecture and the ticket, and where the ticket is silent they fill the gap with reasonable assumptions that may not match anyone else’s. AI now sits inside this chain too, producing fluent, confident code at a speed no reviewer can fully keep pace with. Business analysts reconcile stakeholders who wanted subtly different things. Testers infer the intent behind a specification that was itself an approximation.

Notice where the loss lives. No individual in this chain is careless; each is competent and doing their job well. The degradation is cumulative, and it accrues in the spaces between roles rather than inside any one of them. Quality, distributed across all these hands, drifts not because someone dropped it but because nobody was ever holding all of it.

This is the system, not the people

It is tempting to read all this as a discipline problem – tighter specs, stricter sign-offs, someone to blame when the delivered thing does not match the drawn thing. That instinct misreads what is happening.

Software delivery is a complex system, not merely a complicated one. Dave Snowden’s Cynefin framework draws the distinction well: a complicated system can be fully analysed and planned in advance by experts, whereas a complex one can only be understood by probing it and responding to what emerges. Delivery, full of interacting people and shifting context, sits firmly in the second category. Richard Cook, writing on how complex systems fail, observed that such systems run in a degraded mode as their normal state – always carrying latent faults, always one coincidence away from trouble, and mostly working anyway.

This is why accountability belongs to the system, not the individuals inside it. W. Edwards Deming made the point decades ago and it has aged well: a bad system will beat a good person every time – he reckoned the overwhelming majority of outcomes are produced by the system rather than the people working within it. Sidney Dekker gave the slow accumulation of small, sensible decisions that ends somewhere nobody intended its name: a drift into failure. The gap between plan and product is that drift. Blaming people for it is like blaming the gardener for autumn.

The cost of a drift nobody authorised

Here is a way to make the loss tangible. Treat each handoff as preserving some fraction of the original intent. Be generous and say 90% survives each step – a high bar in practice. Across seven handoffs, from requirement to production, you retain 0.9 to the seventh power: roughly 48%. On flattering assumptions, more than half the original intent has quietly degraded by the time the feature ships.

That figure is an illustration, not a measurement – a way to picture accumulation, not a benchmark to quote. But the mechanism it describes is real, and it has a price. Picture a £750,000 programme built to a business goal that shifted by degrees across the chain, so that what ships technically works but no longer does the job it was funded to do. The rebuild is one cost. The quarter it took to notice, while a competitor moved, is the larger one. None of it surfaces on a status report, because at every stage the work looked correct – against the slightly wrong version of intent that reached that stage.

AI raises the throughput, not the fidelity

The current wave of AI tooling is often sold as a way to remove this variability. It is worth being precise about what it actually does. AI is a new input source in the chain – a fast, fluent one – and it amplifies whatever is already there. Point it at a team with strong feedback and clear intent, and it accelerates good work. Point it at an ambiguous requirement, and it generates plausible, confident output that makes drift harder to spot rather than easier, because polish reads as correctness.

Where you place it decides everything. Wired into the feedback, sensing where output has diverged from intent, it helps hold the system in order. Bolted onto production as a way to generate more, faster, it adds entropy at machine speed and dresses the result in enough polish to pass review. Same tool, opposite effect.

Testing isn’t the gate — it’s the energy you put back in

The plan was never going to be what happened. From the moment it was signed, entropy began pulling the work away from it – not because the project was run badly, but because that is what complex, human systems do. The plan’s real job was never to be obeyed; it was to give you something to measure the drift against. What decides the outcome is whether anyone is spending the energy to notice that drift and pull the work back towards its intent.

This reframes what testing is for. Testing at the end, as a gate that checks the product against the plan, treats the plan as truth and the drift as deviation to be punished. But you cannot assure quality into a product or delivery that way. Leaving it until a gate at the end is far too late.

THE LEADERSHIP QUESTION “How much of your original intent actually reaches production intact — and who is watching the gap?” Ask your delivery leadership to trace one recent feature from the requirement that funded it to the thing that shipped. If they can show you where intent was checked along the way, you have a system that senses drift. If the only checkpoint was at the end, you have a plan and a hope.

Seen through the lens of entropy, information you gain from testing is the energy you feed back into the system to hold it in order. Good testing is a continuous pulse that reveals, throughout delivery, where the work has bent away from intent while the bend is still small and correctable.

Sources

Ashby, D. Writing on quality as a distributed system rather than a single activity, and on testing as the production of information. danashby.co.uk

Lehman, M. M. (1996). “Laws of Software Evolution Revisited.” EWSPT — the laws of Continuing Change, Increasing Complexity (described as an analogue of the second law of thermodynamics) and Feedback System.

Deming, W. E. “A bad system will beat a good person every time,” and the view that the great majority of outcomes are produced by the system. The W. Edwards Deming Institute, deming.org

Cook, R. I. (2000). How Complex Systems Fail. Cognitive Technologies Laboratory, University of Chicago.

Dekker, S. (2011). Drift into Failure: From Hunting Broken Components to Understanding Complex Systems. Ashgate.

Snowden, D. J. & Boone, M. E. (2007). “A Leader’s Framework for Decision Making.” Harvard Business Review (the Cynefin framework).

Hollnagel, E. (2014). Safety-I and Safety-II (work-as-imagined vs work-as-done). Ashgate.

DORA / Google Cloud. Accelerate State of DevOps research programme, on fast feedback and delivery performance. dora.dev