Knight-Ware Labs All Articles
Software Architecture

Under the Streets Before the Smell: Bazalgette's Case for Refactoring Ahead of the Crisis

By Knight-Ware Labs Software Architecture
Under the Streets Before the Smell: Bazalgette's Case for Refactoring Ahead of the Crisis

Photo: nottsexminer, CC BY-SA 2.0, via Wikimedia Commons

In the summer of 1858 the River Thames did something no committee report had managed in a decade: it made the case for its own replacement. The stench drove members from the committee rooms of the Palace of Westminster, drapes soaked in chloride of lime, and within a matter of weeks a scheme that had twice been shelved was on the statute book. Joseph Bazalgette's intercepting sewers followed — some 1,100 miles of main sewer, 82 miles of intercepting conduit, and a drainage network that still carries a substantial share of the capital's waste more than a century and a half later.

The temptation for engineers is to read this as a tale of heroism under pressure. It is more usefully read as a study in the price of deferral. The design existed before the smell. The evidence existed before the smell. What the smell supplied was not architectural insight but political permission — and permission is the scarcest input in any modernisation programme.

The plan that was already on the shelf

The Metropolitan Board of Works had considered Bazalgette's proposals in 1856 and judged them extravagant. Earlier still, Edwin Chadwick had argued for integrated drainage and been resisted by vestries protecting their own rates. In 1854 John Snow had mapped the Broad Street pump and demonstrated, with a clarity his contemporaries could not easily dismiss, that cholera travelled in water rather than air. Every ingredient of the eventual solution was in place years before construction began: the engineering, the epidemiology, the arithmetic.

What was missing was a mandate. The same pattern recurs in software estates with numbing regularity. The replacement of a runtime that left support two years ago, the extraction of a shared database that four teams write to directly, the retirement of an authentication service held together by folklore — all of these are usually well understood internally long before they are funded. The work is not blocked by ignorance. It is blocked by the absence of a sufficiently alarming smell.

Debt that accumulates below the waterline

Application debt announces itself. Pages are slow, tickets accumulate, the error budget burns in public and someone is paged. Platform debt does none of this. It sits in the infrastructure layer — an undocumented nightly batch job, a single-region primary database, credentials rotated by hand, a certificate renewed from memory, a message broker configured by a former employee in 2019 — and it is entirely silent until the moment it is catastrophic.

This asymmetry is precisely why platform work loses every budget negotiation. The benefit of a sewer is an absence: no outbreak, no flooding, no inquiry. Absences do not photograph well in a board pack. Engineers who wish to be funded must therefore learn to make the invisible legible, which is a communication discipline as much as a technical one.

Coupling is the effluent

Bazalgette's decisive move was not the size of his pipes but the principle of separation. Foul water was intercepted before it reached the river; surface water was given its own path. The system worked because the boundary was drawn deliberately rather than allowed to emerge from convenience.

In a software estate the equivalent effluent is coupling that nobody designed. It appears as shared tables read directly by services that have no business knowing the schema, caches that quietly become sources of truth, and internal endpoints treated as public contracts because they happen to be reachable. Each is a small convenience and a large liability, and the liability only crystallises at the point of change — which is to say, exactly when you can least afford it.

A modernisation programme with an owner and a stop condition

The practical lesson is that remediation must be funded as a standing capital programme rather than a contingency line. A programme has an owner, a scope, a cadence and a definition of done. A contingency line has none of these and is raided the moment delivery pressure rises. In the UK public and private sectors alike, the difference between the two is usually the difference between a system that is modernised and one that is merely apologised for.

Three mechanics make the programme credible. First, a ring-fenced allocation expressed as a proportion of engineering capacity rather than a cash figure, so that it survives the annual planning cycle. Second, a published dependency register that names the services, versions and contracts at risk. Third, a stop condition: the point at which the work is done and the team disbands, which prevents modernisation from becoming an unaccountable permanent institution.

You cannot refactor what you cannot see

Snow's map worked because it converted scattered mortality data into a spatial pattern that could be argued with. The software equivalent is dependency observability: which services call which deprecated endpoints, how much traffic still arrives on the old schema, which jobs touch the legacy tables after midnight. Without that instrumentation, every proposal is an assertion and every assertion invites a counter-assertion from whoever holds the budget.

The eighteen-day window

The Great Stink is remembered because it changed behaviour. It did so only because the plan, the evidence and the sponsor were all in place when the window opened. The lesson for architects in 2026 is not to wait for a smell, but to keep the drawings current, the measurements honest and the business case rehearsed — so that when the smell arrives, the decision takes weeks rather than decades.