The Missing Door: A £300 Lesson in Technical Debt

How a Sunday morning disaster confirmed everything about compound interest in software

Sunday morning, two weeks before Christmas. My wife toasts a teacake, the power trips. The fuse box is in the garage. The garage door is electric. There's no manual override. There's no internal door.

Minutes later, I'm sawing through my hallway wall.

This is a story about shortcuts, cascading failures, and why your software platform is three bad decisions away from the same fate.

Part 1: The Anatomy of Cascading Failure

Our new-build house came without an internal door between the garage and the house. A minor omission, barely worth mentioning during the sales process. "The lintel's already there," the site manager assured me. I could even see it. "Dead easy to add whenever you want. Just cut through the blockwork, frame it up, and hang a fire door. Two hours' work, maximum."

He was technically correct. He was also catastrophically wrong.

The first compromise came two months after moving in. My wife struggled with the heavy double garage door, a single panel that required significant force to lift. The obvious solution was to fit the internal door. The more straightforward solution was to motorise the garage door. £300 and two hours later, we had electric operation. The installer asked if we had another way into the garage. "In case of power failure," he explained. I pointed to where the internal door would go. "I'll be fitting that soon," I said.

That was 6 months ago.

The Cascade Begins

Between work, decorating, and life, the door kept sliding down the priority list. We were in and out of the garage constantly, with gardening equipment, Christmas decorations, and tools for the endless new-house projects. But the electric door worked perfectly. Press the button, and the door opens. Why spend a weekend cutting through walls?

8:30 AM, December 11th.

The toaster goes down. Power trips. The kitchen goes dark. No problem, quick flip of the circuit breaker, and we're back in business. Except that the circuit breaker is in the garage. Behind the steel electric door. Which no longer has power. With no manual override. And no internal access.

The following hours confirmed everything I needed to know about technical debt.

Cutting a hole in the hallway wall in -2C weather and snowing outside, just large enough to squeeze through to get to the fuse box. The following hours were spent going to B&Q to buy insulation and expanding foam to patch the hole I had just knocked into a brand-new house. I was frustrated that I knew the risks, yet like all of us, I played them and this time I lost.

The Hidden Architecture of Failure

A week or so later, between Christmas and New Year, I decided to solve the problem myself. I had the tools. I had the door frame sitting in that same garage. I even had the time.

What I didn't have was information about what lay hidden in my walls.

UK building regulations are clear: electrical cables should run vertically or horizontally from visible fixtures, never diagonally. This allows future workers to predict safe zones for drilling or cutting. The electricians who wired my house either didn't know or didn't care. They'd run cables diagonally under the staircase, directly through the zone where the missing door should go. They knew someone might cut there, the lintel was already installed. They did it anyway.

11:00 AM, December 28th

I scanned the wall for wires, but the insulation between the plaster and the breeze blocks has foil on it. No plugs below, and who would put wires where they know a door may be cut? They put a lintel in already. Moments later, my saw meets the ring main. The blade next meets the fibre optic cable a second later. What should have been a simple door installation becomes an emergency repair requiring:

• Emergency electrician: £800
• Fibre Optic repair: £300
• Mobile Internet Charges: £400
• Door installation (now with complications): £500
• Wall repairs and making good: £400
• My time: Four days
• Family stress: Unquantifiable
• Trust in "easy fixes": Gone

Total cost: £2,400
Original quote for door during build: £300
Multiplication factor: 8x

Part 2: Your Platform Has Missing Doors

Every software platform I've worked with in twenty years has its version of my missing door. It's the authentication system everyone's afraid to touch. The deployment process only works from a developer's laptop. The data pipeline held together with cron jobs and hope. The PDF generator that's one update away from catastrophic failure.

These aren't bugs. They're architectural decisions deferred, shortcuts institutionalised, and problems promoted to features.

The Parallel Architecture

Let me map my house to your platform:

The Missing Door = The Deferred Refactor
"We'll add proper error handling in v2." "The authentication rewrite is on the roadmap." "We know the database schema needs work." Always acknowledged, never actioned. The lintel's there, the hard part's done, right? Wrong. The hard part is everything you don't know about yet.

The Motorised Garage = The Tactical Workaround
Instead of solving the root problem, we implement a workaround that appears to function perfectly. API Gateway instead of fixing authentication. Caching layer instead of optimising queries. More servers instead of efficient code. Each workaround adds complexity, creates dependencies, and makes the real fix harder.

The Diagonal Cables = The Hidden Violations
Every codebase has them. The hardcoded credentials that "no one will ever see." The SQL injection vulnerability in the admin panel "that's behind a firewall." The test data became production data. The shortcuts that violate every principle but work today. They're invisible until someone cuts through the wall.

The Power Trip = The Triggering Event
It's always something innocuous. A certificate expires. Supplier changes an API. A developer leaves, and their personal access token expires. Server updates and breaks your parser. The toaster went down, and suddenly, you discovered your entire architecture has a single point of failure you never documented.

The Multiplication Table

In my experience across multiple platform transformations, I've observed a consistent pattern:

 My door followed this exactly. £300 during construction. £400 workaround at two months. £2,400 at eighteen months during the crisis.

Part 3: The Industry Pattern Nobody Discusses

The construction industry offers a perfect parallel to software. Both industries operate on similar dynamics: competitive markets, pressure for speed, quality as a "nice to have," and accountability gaps between creation and consequence.

The Construction Playbook

Recent years have seen major UK housebuilders face scrutiny over build quality. Independent reviews have found systemic issues. Fire safety problems. Missing insulation. Incorrectly installed barriers. Yet the industry continues to thrive. Share prices recover. Profits remain strong. Executive compensation reaches record highs.

Why? Because the incentive structure rewards shortcuts:

1. Speed to Market: First to build captures the buyers
2. Quarterly Targets: Hit numbers now, handle problems later
3. Warranty Arbitrage: Two-year warranty, five-year problem emergence
4. Cost Externalisation: Problems become the owner's responsibility
5. Reputation Lag: Brand damage trails problem emergence by years

The Software Playbook

The software industry has perfected this model:

1. First Mover Advantage: Ship features before competitors
2. Growth Metrics: Users and revenue trump reliability
3. Technical Debt Invisibility: Not on balance sheets
4. Talent Mobility: Leave before consequences arrive
5. Acquisition Exit: Sell before rebuild becomes necessary

The Critical Difference: In construction, problems eventually become visible, cracks appear, roofs leak, and foundations shift. In software, issues often manifest as increased hosting bills, longer deployment times, and developer turnover. The rot is invisible until the structure collapses.

The Timeline Mismatch

The software industry has a timing problem that research confirms:

According to a Korn Ferry study of the 1,000 largest U.S. companies, average C-suite tenure is 4.9 years, with CEOs averaging 6.9 years. While specific CTO data wasn't broken out, the C-suite average suggests technical leadership changes every 4-5 years.

(Age and Tenure in the C-Suite: Korn Ferry Study Reveals Trends by Title and Industry)

Meanwhile, McKinsey research found that technical debt amounts to 20-40% of a company's entire technology estate value. The Consortium for Information & Software Quality estimates U.S. technical debt at $1.52 trillion - a number that keeps growing.

(Tame tech debt to modernize your business | McKinsey)

The Stripe Developer Coefficient study found developers spend 41% of their time on technical debt and maintenance - time that could be spent on innovation. That's 13.5 hours per week, every week.

(the-developer-coefficient.pdf)

Standard executive equity vesting remains at 4 years across the industry. The people making architectural decisions rarely stay long enough to face the full consequences of their shortcuts.

Part 4: The Real Cost Mathematics

My missing door taught me that technical debt isn't just about code – it's about compound interest on deferred decisions.

The Visible Costs

These are the costs we track, discuss, and occasionally budget for:

My House:

• Door installation: £500
• Electrician: £800
• Mobile Internet Fees: £400
• Internet repair: £300
• Wall repairs: £400
• Total: £2,400

Your Platform:

• Additional developer time
• Infrastructure scaling costs
• Bug fixes and patches
• External consultants
• Emergency support

The Hidden Costs

These are the costs that destroy companies:

My House:

• Four days of my time (opportunity cost)
• Stress and relationship strain
• Ongoing anxiety about unknown problems

Your Platform:

• Developer turnover: £90,000 per senior engineer who leaves in frustration
• Velocity degradation: 3-6 month features becoming 12-month projects
• Customer churn: 5x customer acquisition cost for each lost client
• Market opportunity loss: Competitors ship while you firefight
• Cultural damage: Team morale destroyed by constant crisis
• M&A haircuts: 20-40% valuation reduction for technical risk
• Recruitment difficulty: Glassdoor reviews warn developers away
• Innovation paralysis: Can't build new because maintaining old consumes everything

The Compound Interest Formula

Based on my experience, technical debt compounds at approximately 15% monthly. Here's why:

Month 0: Original shortcut

Month 1: Dependencies begin forming (1 system relies on shortcut)

Month 3: Workarounds accumulate (3 systems now depend on it)

Month 6: Documentation gaps widen (nobody remembers why)

Month 12: Original developer leaves (knowledge walks out)

Month 18: Fear sets in (everyone afraid to touch it)

Month 24: Crystallisation (becomes "how we do things")

At 15% monthly compound rate:

• 6 months: 2.3x original cost
• 12 months: 5.4x original cost
• 18 months: 12.4x original cost
• 24 months: 28.6x original cost

My door at month 18: 8x cost. Your authentication system at month 24?

Part 5: Ideas on some frameworks to help

Frameworks that treat technical debt like financial debt – with covenants, triggers, and accountability.

The 20/20/20 Rule

20% Capacity Allocation

• Non-negotiable: 20% of engineering capacity on debt reduction
• Measured weekly, reported monthly
• Protected from "emergency" raids
• Treated like taxation, not charity

20% Debt-to-Velocity Ratio

• Technical Debt Ratio (TDR) = Hours to fix known debt / Total velocity
• Measured quarterly
• Board-reported metric
• Triggers automatic action above threshold

20% Compensation Alignment

• Executive bonuses tied to technical health
• Vesting contingent on debt metrics
• Clawbacks for post-departure discoveries
• Success = sustainable growth, not just growth

The Breach Triggers

Stop treating technical problems as suggestions. Make them automatic:

 The Accountability Metrics

Technical Debt Ratio (TDR)

• Estimated hours to fix known issues / Total development hours
• Target: <20%
• Reality check: Most platforms run 50-80%

Developer Confidence

• Anonymous quarterly survey
• "How confident are you deploying to production?"
• "Would you recommend this codebase to a friend?"
• "How many hours per week do you spend on preventable issues?"

Customer Impact Score (CIS)

• (Support tickets × Average severity × Resolution time) / Active users
• Trend is more important than absolute
• Leading indicator of churn

The Board Report Template

Every quarter, technical leadership presents:

·         Current Technical Debt Ratio

·         Current Developer Confidence

·         Customer Impact Score

·         Top 3 technical risks - Risk, Impact if realised & Mitigation plan

·         Debt reduction this quarter - System, What we fixed & Impact

·         Debt incurred this quarter - Decision, Why & Planned remediation

·         Resource allocation - Feature Development: %, Debt Reduction: % (Target: 20%) & Support/Maintenance: %

Part 6: The Conversation We Need to Have

The software industry needs to acknowledge an uncomfortable truth: we've optimised for the wrong metrics. We celebrate velocity while ignoring sustainability. We reward shipping features while punishing maintenance.

The Questions for Your Board

1. "What's our plan when the CTO leaves?"
   • Not if, when. Average tenure is 4.1 years.
   • Who understands the architectural decisions?
   • What's documented vs what's in heads?
2. "What breaks if our most senior engineer quits tomorrow?"
   • Every platform has a "Dave" who knows the secrets
   • What's the bus factor for critical systems?
   • How much would you pay them as a contractor?
3. "How much would it cost to rebuild from scratch?"
   • This is your maximum technical debt
   • If it's more than annual revenue, you have a problem
   • If you don't know, you definitely have a problem
4. "Would you invest in us knowing what engineering knows?"
   • Ask your senior engineers privately
   • The answer might shock you
   • Their silence is also an answer

The Cultural Shift Required

We need to stop celebrating heroes who fix production at 3 AM and start celebrating engineers who ensure production doesn't break. We need to stop rewarding velocity without sustainability and start measuring the total cost of features, including their maintenance tail. We need to stop treating technical debt as inevitable and start treating it as a choice.

From my house, three lessons:

1. Every shortcut has a beneficiary and a victim - usually separated by time
2. Invisible problems compound faster than visible ones
3. The cost of fixing grows exponentially, and the will to fix declines linearly

Conclusion: The Door Always Needs Fitting

Each problem can be traced back to someone who saved an hour or a hundred pounds during construction.

The builder saved £300 by not fitting my door. I paid £2,400 eighteen months later. They're still building houses.

Your platform is no different. Somewhere, there's a missing door. Diagonal cables run through your walls. The lintel's there, waiting for someone to cut through and discover what's hidden. The only question is whether you'll address it on your schedule or find it on a Sunday morning when someone makes toast.

The software industry has a choice. We can continue down the path of the construction industry, where shortcuts become strategy, quality becomes optional, and customers bear the cost. Or we can acknowledge that technical debt is a choice, that sustainability matters, and that the actual cost of software includes its entire lifecycle, not just its ship date.

The door always costs £300. The only variable is when you pay and how much interest you've accrued.

What's your plan when the power trips?