Stone Upon Stone: The Hidden Price of Over-Fortifying Your Software Core

Stand at the base of Warwick Castle's keep and you are confronted with something genuinely impressive: walls up to three metres thick, constructed to repel battering rams, siege engines, and the sustained fury of medieval warfare. The engineering is extraordinary. It is also, by any contemporary measure, entirely redundant.

No one is bringing a trebuchet to Warwickshire in 2025. Yet the stone remains, immovable, consuming space, demanding maintenance, and shaping everything built around it.

Software architects will recognise this predicament immediately.

The Defensive Instinct That Never Switches Off

When a system is first conceived under genuine pressure—regulatory uncertainty, volatile load patterns, poorly understood external dependencies—the instinct to over-engineer its core is entirely rational. Engineers add layers. They build abstraction upon abstraction. They provision for failure modes that, at the time, seem entirely plausible.

The problem is that threats evolve. Regulatory frameworks change. External APIs stabilise. Traffic patterns become predictable. The siege, in short, never arrives—or arrives once, is repelled, and then retreats permanently.

But the fortifications remain.

In medieval castle architecture, this manifested as keeps that grew increasingly elaborate long after the military justification had passed. The Tower of London, begun under William the Conqueror, accumulated towers, walls, and defensive structures across centuries. Many additions addressed threats that were already obsolete by the time the mortar dried. The result was an architectural palimpsest: layer upon layer of defensive logic, each coherent in isolation, collectively forming something that required an entire garrison simply to maintain.

Your monolithic authentication service, your twelve-stage validation pipeline, your triple-redundant message broker—sound familiar?

What a Keep Actually Costs

Historians of medieval fortification are careful to distinguish between the visible cost of a castle and its operational cost. Construction was expensive. Maintenance was ruinous. A garrison had to be fed, paid, and housed. The keep demanded constant upkeep regardless of whether anyone was actively attacking it.

Software carries precisely the same economics. An over-engineered core system imposes costs that compound quietly and persistently:

• Onboarding friction. New engineers spend weeks—sometimes months—deciphering defensive layers that serve no active purpose. Documentation, where it exists at all, describes the original threat model, not the current operational reality.
• Change velocity. Modifying anything adjacent to the core becomes a careful archaeological exercise. Teams learn to route around complexity rather than through it, producing the software equivalent of a castle town built entirely outside the walls.
• Incident surface. Counter-intuitively, complexity does not reduce risk—it redistributes and obscures it. The more defensive layers a system carries, the more places a failure can originate and the harder it becomes to trace.
• Cognitive overhead. Senior engineers who understand the original fortification logic become single points of failure. When they leave, the institutional memory of why each layer exists departs with them.

This is not a theoretical concern. It is the daily operational reality of a significant proportion of Britain's enterprise software estate.

Identifying Your Legacy Fortifications

Before dismantling anything, you must understand what you are looking at. Medieval architects left physical evidence of their intentions—arrow loops positioned for specific angles of fire, murder holes placed above particular approaches. Your codebase carries equivalent archaeological markers.

Begin by asking three questions of every component in your core system:

What threat does this defend against? If the answer requires significant research or produces uncertainty, that is meaningful. If the answer is 'a requirement from a system we no longer integrate with' or 'a compliance obligation that was revised four years ago', you have found a candidate for review.

When was this last exercised? Defensive code that is never triggered is not neutral—it is a liability. Examine your observability data. If a circuit breaker has not tripped in three years, the question is not whether it can be removed but whether the threat model that justified it still applies.

What would break if this were absent? This is the most important question, and it demands honest answers rather than speculative ones. Trace the actual dependencies. Write the tests. Build the understanding before you touch anything.

Dismantling Without Destabilising

The worst approach to legacy fortification is the one most commonly attempted: the grand refactor. Teams announce an intention to 'modernise the core', allocate a sprint or two, discover the depth of the problem, and abandon the effort having added confusion without reducing complexity.

Medieval castles were rarely demolished in a single campaign. They were adapted incrementally—towers repurposed, walls lowered, moats filled. The structural logic was respected even as the defensive purpose was retired.

The same discipline applies here. Consider the following approach:

Isolate before you extract. Before removing a defensive layer, wrap it. Introduce a seam that allows the layer to be bypassed in controlled conditions. This is not merely good practice—it is the mechanism by which you generate the evidence needed to justify removal.

Shadow mode first. Run the simplified path in parallel with the fortified one. Log divergences. If none appear over a meaningful period under representative load, the case for removal becomes empirical rather than theoretical.

Retire by feature flag. Remove the fortification incrementally, by traffic segment or by environment. This is not timidity—it is the engineering equivalent of lowering the drawbridge before filling in the moat.

Document the retirement. This is the step most frequently skipped, and its omission is how the next generation of engineers ends up rebuilding the same fortifications from scratch. Record what was removed, why it existed, what evidence justified its removal, and what monitoring was put in place to detect if the original threat re-emerges.

The Keep That Earns Its Keep

None of this is an argument against robust core architecture. Warwick Castle's keep was not a mistake—it was an appropriate response to the threat environment of its era. The mistake is allowing that response to calcify into permanent, unexamined infrastructure.

The strongest core systems are not those with the most defensive layers. They are those whose every layer can be justified against a current, documented threat. They are systems whose architects can explain not only what each component does, but why it remains necessary.

At Knight-Ware Labs, we have observed that the engineering teams who build the most resilient systems are rarely those who build the most complex ones. They are the teams disciplined enough to ask, regularly and honestly, whether the fortifications they inherited are still earning their operational cost.

The keep was built for a siege that may never come again. The question worth asking, on any given Wednesday morning, is whether you are still paying the garrison.