Never Finished, Sometimes Abandoned: What Cathedral Builders Teach Us About Knowing When to Stop
Stand in the nave of Salisbury Cathedral and you are standing inside a decision that took 38 years to execute, completed in 1320 to a design that had been continuously revised since the foundation stone was laid in 1220. Stand, by contrast, at the ruins of Coventry's old cathedral — not the Blitz ruin, but the earlier St Mary's Priory, begun in the fourteenth century and never completed to its original ambition — and you are standing inside a different kind of decision: the point at which resource reality finally defeated architectural aspiration.
Both outcomes were the result of choices. The question that medieval builders faced — and that software teams face with uncomfortable regularity — is not simply whether a project is worth pursuing, but whether it is worth continuing. Those are different questions, and conflating them is how organisations end up committing five years to an initiative that warranted eighteen months.
The Sunk Cost Nave
Medieval cathedral construction was financed through an accumulation of donations, indulgences, episcopal patronage, and civic pride. Once a significant portion of a structure was complete, the social and theological pressure to continue was immense. A half-built nave was not merely an architectural inconvenience — it was a visible symbol of incomplete devotion, a source of embarrassment to the diocese that had commissioned it.
This is the sunk cost fallacy rendered in stone. The investment already made in the foundations, the columns, the partially completed choir, exerted gravitational pull on subsequent decisions, making continuation feel obligatory even when the original rationale had dissolved or the available resources had diminished.
Software projects generate the same gravitational field. A team that has spent two years building a platform begins to treat continued investment as a moral obligation rather than an economic decision. The two years already spent are not recoverable regardless of what happens next — but they feel like justification for the next two years, and the two after that.
The cathedral builders who completed their structures successfully were not those who felt this pull most keenly. They were those who periodically reassessed whether the original vision remained achievable and appropriate, and who were willing to revise scope — sometimes dramatically — when circumstances demanded it.
Scope Revision as Survival Strategy
Salisbury's spire, the tallest in England at 123 metres, was not part of the original design. It was added in the fourteenth century, decades after the main structure was complete, when both the engineering capability and the financial resources to realise it became available. Conversely, many cathedrals that were originally planned with elaborate western towers were completed with simpler facades when funds ran short — the ambition was preserved where it mattered most, and curtailed where the cost was prohibitive.
This is not failure. It is responsive scope management: the willingness to distinguish between the core value proposition of a project and the aspirational features that were appended to it during the optimism of initial planning.
In software terms, this is the difference between a minimum viable product that delivers genuine value and a feature-complete vision that delivers nothing until the very end — if it ever arrives. The cathedrals that were completed were, almost without exception, those whose builders were willing to make this distinction under pressure.
The ones that were abandoned tended to share a different characteristic: they had been designed as indivisible wholes, such that no partial version of the project was useful or presentable. When resources contracted — as they inevitably did, through plague, economic disruption, or the death of a patron — there was no fallback position. The choice became all or nothing, and nothing frequently won.
The Five Questions Before Year Three
For engineering leaders managing significant initiatives, the medieval record suggests a set of questions worth asking before a project reaches the point at which sunk cost psychology begins to distort judgement. Ideally, these questions are asked at regular intervals from the outset — but they become critical somewhere around the point at which a project has consumed enough resource to feel irreversible.
Does the original problem still exist in the form we assumed? Markets change. Organisational priorities shift. Regulatory environments evolve. A project that was solving a genuine problem eighteen months ago may be solving a problem that has since been addressed by other means, or that has ceased to be a priority. Confirm that the foundation is still load-bearing before adding another floor.
Is the value deliverable incrementally, or only at completion? If the answer is only at completion, that is a significant risk flag. Restructure the project to deliver partial value at intermediate stages, or be very explicit about the commitment required to reach a useful endpoint.
What is the realistic cost to completion, stated honestly? Not the original estimate. Not the revised estimate from six months ago. The current, unvarnished assessment from the people doing the work. Medieval construction projects that overran catastrophically were almost always those in which optimistic estimates were preserved long after evidence had undermined them.
What would we do with the resources if this project were cancelled today? This question is not a threat — it is a calibration. If the answer is 'nothing better than this', continue with confidence. If the answer reveals three higher-priority initiatives that are being starved, that information belongs in the decision.
What does a dignified partial completion look like? Even if full completion is no longer viable, is there a version of this project that delivers meaningful value and can be closed cleanly? The cathedral builders who ran out of funds sometimes completed the choir and chancel — the liturgically essential portions — and left the nave unbuilt. The building functioned. The congregation was served. The ambition was preserved for a later generation with more resources.
The Decision to Abandon Is a Decision, Not a Failure
There is a cultural tendency in software organisations to treat project cancellation as evidence of failure — of poor planning, poor execution, or poor judgement. This framing is both inaccurate and harmful. It discourages honest reassessment and encourages the continued investment of resource in initiatives that no longer merit it.
The medieval bishops who halted construction on overambitious projects were not regarded as failures by their contemporaries. They were regarded as pragmatists who had preserved the diocese's resources for more achievable ends. The stigma attached to stopping is largely modern, and it is largely misplaced.
At Knight-Ware Labs, we would frame the question this way: the engineering discipline required to continue a difficult project and the engineering discipline required to stop one are both forms of craft. The latter is rarer, harder to exercise, and — in the right circumstances — more valuable.
Knowing when a project is a cathedral worth completing and when it is a ruin worth preserving as a lesson is not a skill that emerges automatically from technical expertise. It requires deliberate practice, honest data, and the organisational courage to act on uncomfortable conclusions.
The builders of Salisbury had all three. The nave stands as proof.