Chapter 5: Technical Debt as a Strategic Instrument
The ideas of debtor and creditor as to what constitutes a good time never coincide.
Love Among the Chickens, 1906
In 1992, Ward Cunningham was building a portfolio management system called WyCash in Smalltalk. He needed to explain something to his business partners — why the engineering team needed to go back and rework code that was already working. The code was not broken. It did what it was supposed to do. But the team’s understanding of the financial domain had evolved since they wrote it, and the code no longer reflected what they now knew. The gap between their current understanding and the code’s representation of that understanding was slowing them down.
Cunningham reached for a financial analogy. "Shipping first time code is like going into debt," he wrote in an experience report for the OOPSLA conference. "A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation."[1]
That passage created the most influential metaphor in software engineering. It also created one of the most misunderstood.
Cunningham’s metaphor was not about messy code. It was not about cutting corners. It was about the inevitable gap between what you know and what your code reflects — a gap that widens as you learn more about the problem you are solving. Seventeen years later, Cunningham recorded a video to correct the record: "A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that was the primary source of debt. I’m never in favor of writing code poorly."[2] The metaphor, properly understood, says something specific: you borrowed against your future understanding to ship today, and the interest you pay is the friction of working with code that no longer matches what you know.
That distinction matters for the startup CTO because it reframes the entire relationship with technical debt. Debt is not a symptom of failure. It is a financing instrument. Like financial debt, it can be used strategically — to accelerate growth, to test a hypothesis, to reach a market window — or it can accumulate recklessly until it consumes every dollar of engineering capacity the company has. The CTO’s job is not to avoid debt. It is to manage it: knowing when to borrow, how much the interest will cost, and when repayment becomes urgent.
A Taxonomy of Debt
Martin Fowler extended Cunningham’s metaphor in 2009 with a framework that remains the clearest tool for categorising the debt a startup accumulates. He proposed two axes — deliberate versus inadvertent, and reckless versus prudent — producing four types of debt.[3]
Reckless-deliberate debt is the decision to skip design because there is no time. The team knows better and chooses not to do better. This is the credit card debt of engineering: easy to incur, high interest, and it compounds. Reckless-inadvertent debt is the result of not knowing better — the team that has never heard of separation of concerns shipping a monolith because they do not know another way. Prudent-deliberate debt is the conscious trade-off: we know this is not the right architecture, but we need to ship this quarter and we will address it afterward. This is the mortgage — a large, tracked obligation taken on to enable something that would otherwise be impossible. Prudent-inadvertent debt is the most subtle and the most aligned with Cunningham’s original meaning: the team ships clean code that reflects their best understanding, and then learns something that makes the design wrong. "Now we know how we should have done it," as Fowler phrases it.[3]
Steve McConnell, author of Code Complete, developed the financial analogy further in a white paper that remains the most systematic treatment of the subject. He distinguishes between focused debt — a large, identifiable shortcut, like a car loan — and unfocused debt: "hundreds or thousands of small shortcuts — generic variable names, sparse comments, creating one class in a case where you should create two." Focused debt can be tracked and managed. Unfocused debt "is like credit card debt. It’s easy to incur unintentionally, it adds up faster than companies think, and it’s harder to track and manage after it has been incurred."[4]
For the startup CTO, a simpler taxonomy may be more useful than either framework in isolation. The debt in your codebase falls into three categories, and each requires a different management strategy.
Debt you chose. This is the mortgage. You shipped a monolith knowing you would need services. You used a third-party authentication library knowing you would need to customise it. You hardcoded configuration values knowing you would need a configuration service. These decisions were rational at the time — they bought speed, validated a hypothesis, or reached a market window. The interest is predictable: you will pay it when you need to scale, customise, or extend the feature. The risk is manageable as long as you track the obligation and schedule repayment before the interest compounds.
Debt you inherited. This is someone else’s mortgage. You joined the company and discovered a codebase shaped by decisions you did not make, for reasons you may not understand. The previous CTO chose a framework that does not scale. A contractor built a feature with no tests. The founding team’s understanding of the domain was different from yours. Kellan Elliott-McCrea, former CTO of Etsy, warns against conflating this with failure: "All code is, to varying degrees, an incorrect bet on what the future will look like."[5] Inherited debt is not a crisis. It is a condition. The CTO’s job is to assess the interest rate, identify which obligations are actively slowing the team, and prioritise repayment based on business impact rather than engineering aesthetics.
Debt you did not know you had. This is the hidden liability — the dependency that has not been updated in two years, the security vulnerability in a library nobody monitors, the assumption about data volume that will break at 10x scale. Elliott-McCrea identifies five distinct phenomena that the industry conflates under the single term "technical debt," including features of the codebase that resist change, operability choices that resist change, and dependencies that resist upgrading.[5] Hidden debt is the most dangerous category because you cannot manage what you cannot see. The debt audit described later in this chapter is designed to surface it.
|
AUTHOR: CorralData’s debt portfolio — which category dominates? Was there a specific moment where inherited debt or hidden debt created a crisis? The healthcare B2B context may add a dimension: compliance-related debt, where a shortcut that was acceptable at one regulatory stage becomes a liability at the next. |
The Cost of Carrying Debt
The financial metaphor is useful only if the interest is real and measurable. It is.
Stripe surveyed thousands of developers and C-level executives in 2018 and found that engineers spend an average of 33% of their time — 13.5 hours per week — dealing with technical debt and maintenance rather than building new features. Stripe extrapolated the global cost at roughly $300 billion per year in lost developer productivity.[6] Stepsize, surveying more than 200 engineering team members in 2021, found the same figure: 33% of development time consumed by maintenance, with more than half of that attributable to technical debt. Fifty-two percent of engineers in the Stepsize survey said debt negatively affected their morale.[7] DX and Atlassian, surveying 2,100 developers and engineering leaders in 2024, found that 69% of developers lose eight or more hours per week to inefficiencies, with technical debt cited as the primary cause by 59% of respondents.[8] The Stack Overflow 2024 Developer Survey — 65,000 respondents, the largest annual survey of working developers — found that 62% cite technical debt as their number one frustration at work.[9]
Four independent surveys, conducted by organisations with no shared methodology and no overlapping commercial interests, converge on the same conclusion: roughly one-third of engineering capacity in the typical software organisation is consumed by debt service. For a startup with 10 engineers, that is 3.3 engineers working full-time on the consequences of past decisions rather than building the product. The Consortium for Information and Software Quality, co-founded by the Object Management Group and the Software Engineering Institute at Carnegie Mellon, estimates that accumulated technical debt across the US software industry stands at $1.52 trillion.[10] McKinsey, surveying 50 CIOs at financial services and technology companies, found that technical debt typically accounts for 20 to 40% of the total technology estate, with 10 to 20% of a company’s technology budget diverted from new products to debt service.[11]
McConnell provides the language for translating this into board-ready communication: "`Shifting the dialog from a technical vocabulary to a financial vocabulary provides a clearer, more understandable framework. Discuss debt in terms of money rather than in terms of features. For example, ‘40% of our current R&D budget is going into supporting previous releases’ or ‘We’re currently spending $2.3 million per year servicing our technical debt.’`"[4] This is the Chapter 10 skill in action — the business acumen that translates engineering reality into language the board can evaluate. The CTO who says "we have a lot of technical debt" is making a complaint. The CTO who says "we are spending 33% of our engineering budget on debt service, and I want to reduce that to 20% over the next two quarters by investing in these three specific migrations" is making a business case.
Fowler offers one important refinement to the interest metaphor. Unlike financial debt, technical debt does not charge interest based on the passage of time. It charges interest based on contact. "I only trigger an interest payment when I have to work with that part of the software. So crufty but stable areas of code can be left alone."[12] This is a critical insight for the startup CTO making prioritisation decisions. Debt in a module that nobody touches costs nothing. Debt in the module that every feature touches costs everything. The interest rate is not a property of the code. It is a property of how often the team needs to change it.
Fowler also introduces the design stamina hypothesis: there exists a point — typically reached within weeks rather than months — after which the cost of working with poorly designed code exceeds the time that better design would have required. Before that point, cutting corners is faster. After that point, the debt is slowing you down more than the shortcut saved. The CTO who understands where this line falls in their codebase can make informed borrowing decisions. The CTO who does not will cross it without noticing and spend the next year wondering why the team cannot ship.[12]
|
AUTHOR: A specific CorralData example of debt cost — a feature that took twice as long as it should have because of accumulated debt, or a calculation showing what percentage of the engineering team’s time goes to maintenance versus new features. The reader needs to see the 33% figure grounded in a real company. |
The Debt Audit
The practical framework the startup CTO needs is not another taxonomy. It is a process for surfacing hidden debt, quantifying its cost, and communicating the results to non-technical colleagues who do not read code.
Google’s approach, documented by Ciera Jaspan and Collin Green of Google Research in IEEE Software, provides the most empirically grounded model. Google runs quarterly engineering surveys that measure technical debt across 10 categories: migrations needed or in progress, poor documentation, inadequate testing, code degradation, teams lacking expertise, dead or abandoned code, poor code quality, delayed dependency updates, API incompatibility, and process debt. The surveys are segmented by engineering domain — teams working on machine learning systems face different debt profiles than teams building backend services — which allows targeted interventions rather than blanket policies.[13]
The result of this systematic approach: Google achieved its largest improvement in five years of measurement, with a majority of engineers reporting only slight or no hindrance from technical debt.[13] The tactics included dedicated "Fixit days," specialised teams — variously called "janitors, cultivators, or demolition experts" — and interventions targeted by product area rather than applied uniformly.
A startup cannot replicate Google’s survey infrastructure. But the principle scales down. Chelsea Troy, a staff software engineer at Mozilla who teaches at the University of Chicago, proposes a measurement framework built around what she calls "maintenance load" — the proportion of total development effort consumed by existing code rather than new capabilities. Track the ratio of tickets that add or change features to tickets that fix, maintain, or work around existing code. If more than 40% of your engineering capacity is going to maintenance, your debt load is affecting your ability to compete. If it is above 50%, it is an emergency.[14]
Troy also identifies the specific mechanism by which debt compounds: context loss events. Every time a team member leaves, every time a module goes untouched for six months, every time an AI tool generates code that nobody reviews — the team’s understanding of the codebase degrades. The code still works. But the ability to change it safely declines. Troy’s formulation: "Code stewardship is a whole, difficult skill that is completely separate from writing feature code, which is what most developers are trained to do and rewarded for by the business."[14]
Will Larson, who led Foundation Engineering at Stripe and managed large-scale migrations at Uber, argues that at scale, migrations are "the sole scalable fix to tech debt." Individual engineers will always pick off low-hanging fruit, but the hard debt — the kind that requires multiple teams to coordinate — can only be addressed through a structured migration process. His playbook has three phases: derisk (write the design document and embed with the hardest teams first, not the easiest), enable (build tooling to programmatically migrate the straightforward cases), and finish (stop the bleeding, generate tracking tickets, push status to management). His warning: "Starting but not finishing migrations often incurs significant technical debt" — worse than never starting at all.[15]
For the seed-stage CTO with a team of five, the debt audit is simpler. Once per quarter, ask three questions. First: where is the team spending unplanned time? The modules that generate the most bug reports, the most "that’s weird" conversations, the most workarounds — those are your highest-interest debts. Second: what would break if we grew 10x? The database schema, the deployment process, the authentication system, the monitoring gaps — these are your hidden debts, the ones that cost nothing today and everything tomorrow. Third: what can we not explain? The module that nobody on the current team wrote, the configuration that nobody understands, the dependency that nobody has updated — these are the debts that resist repayment because the knowledge needed to repay them has been lost.
|
AUTHOR: How CorralData conducts its own debt assessment — formally or informally? Is there a regular process, or does debt surface ad hoc? A worked example of the three-question audit applied to CorralData would give the reader a template they can use immediately. |
AI Is a New Kind of Debt
Chapter 12 examines the AI transformation in full. Here, the concern is narrower: AI coding tools are generating a new category of technical debt that does not fit cleanly into any existing framework.
GitClear, analysing 211 million changed lines of code across repositories owned by major technology companies, documented a structural shift between 2020 and 2024 that coincided with the adoption of AI coding assistants. Refactoring — the practice of reorganising code to improve its structure — dropped from 24% of all changed lines to under 10%. Copy-pasted code rose from 8.3% to 12.3%. For the first time in GitClear’s measurement history, duplicated code exceeded refactored code. Duplicate code blocks of five or more lines increased roughly eightfold during 2024.[16]
The Google DORA team’s 2024 report, surveying approximately 39,000 professionals, found that while 75% of developers reported individual productivity gains from AI tools, each 25% increase in AI adoption was accompanied by an estimated 7.2% decrease in delivery stability.[17] Individual speed went up. System reliability went down. This is the debt metaphor operating at industrial scale: AI tools borrow against future maintainability to deliver present velocity.
Kent Beck, who created Extreme Programming and Test-Driven Development, describes the mechanism precisely. AI coding assistants add features but never improve structure. A function that is already too long gets 20 more lines. A field that should be accessed through an interface gets accessed directly 20 more times. Beck calls this "eating the seed corn" — consuming the design investment that future development depends on. Eventually, he writes, "the friction created exceeds the genie’s capacity. We are out of options. The genie spins for hours without being able to correctly implement the next feature."[18]
Margaret-Anne Storey, a professor of computer science at the University of Victoria, coined the term "cognitive debt" to describe a dimension of AI-generated debt that has no precedent in traditional software engineering. Even when AI-generated code is functional and well-structured, the humans working with it may have lost their understanding of what the code does, why it works, and how to change it safely.[19] Traditional technical debt degrades the code. Cognitive debt degrades the team’s relationship to the code. Both charge interest. But cognitive debt is harder to measure and harder to repay, because the remedy is not refactoring — it is learning, which takes time that AI adoption was supposed to save.
The management strategy for AI-generated debt is straightforward in principle and demanding in practice. Review what the model produces — not for correctness, which is the easy part, but for structure, duplication, and architectural coherence, which are the dimensions the model does not optimise for. Maintain test coverage as a constraint, not a suggestion — Beck’s warning sign that AI is going off track is when the model deletes or disables tests to make its implementation work.[18] And track the metrics that reveal debt accumulation: the ratio of new code to refactored code, the duplication rate, and the time engineers spend understanding code they did not write. These are the leading indicators. By the time delivery stability declines, the debt has already compounded.
|
AUTHOR: CorralData’s specific experience with AI-generated debt — code produced by LLM tools that required rework, a pattern you’ve observed in how AI tools handle your healthcare data models, or a process you’ve built to catch structural problems before they compound. The reader needs to see this new category of debt acknowledged by a CTO who uses AI tools daily. |
When the Strategy Changes, the Code Becomes Debt Overnight
Every category of debt described so far — chosen, inherited, hidden, AI-generated — accumulates gradually. There is one scenario in which the entire codebase becomes debt in a single conversation: the pivot.
When a startup changes its market, its product, or its business model, every line of code that was correct for the old strategy becomes a liability for the new one. Not because it was badly written. Not because the team cut corners. Because the company’s understanding of what it is building has shifted wholesale — which is Cunningham’s original metaphor operating at the scale of the entire business rather than a single module.
The canonical pivot stories reveal a spectrum. At one end: YouTube pivoted from a video dating site to a general video platform in approximately one week. Steve Chen, co-founder and CTO, describes the sequence: they launched the dating site, zero videos were uploaded in the first week, and they opened the platform to all content.[20] The technical infrastructure — the upload pipeline, the Flash-based transcoding engine, the hosting architecture — survived intact. The pivot was a positioning change, not a technical one. Nearly everything carried over.
At the other end: Stewart Butterfield spent years building Glitch, a massively multiplayer online game, before shutting it down and building Slack from the internal communication tool his team had hacked together during development. The game was built on Flash — a dying platform after Apple refused to support it on the iPhone. CTO Cal Henderson has noted that the Flash dependency meant they could not pivot the game itself; the technology platform was a dead end.[21] Slack was built from scratch, in a different stack, for a different market. What survived was not code but knowledge: how real-time messaging should feel, what made a communication tool sticky, and the conviction that the internal tool they had built for themselves was more valuable than the game it was supposed to support. Butterfield’s pitch to the remaining team captured the transition: "We’ll get rid of all the stuff we’ve duct-taped together and start fresh, but keep everything we’ve learned."[21]
Between these extremes sits Shopify, the most instructive case for the CTO thinking about debt. Tobias Lütke built an online snowboard store called Snow Devil in Ruby on Rails in 2004. When he could not find adequate e-commerce software, he built his own. The pivot — from snowboard retailer to e-commerce platform — was a generalisation: same domain, broader audience. Lütke describes the continuity: "In the end, Shopify is the software that I hoped to find in 2004 for Snowdevil."[22] The codebase did not die. It evolved over eighteen months from a single-tenant store to a multi-tenant platform. Two open-source libraries Lütke wrote for Snow Devil — Liquid (a templating language) and ActiveMerchant (a payment processing abstraction) — remain core Shopify infrastructure today. Shopify still runs on Ruby on Rails in 2025.
Instagram and Twitter complete the spectrum. Krieger and Systrom stripped their location-based social app Burbn down to a single feature — photo sharing — and rewrote the entire application in eight weeks. The insight survived; the code did not. Twitter was prototyped in two weeks inside Odeo, a podcast platform. Both used Ruby on Rails; no podcast code was relevant to a microblogging service.
The pattern is clear, and it is the pattern the CTO needs to internalise: the type of pivot determines whether the code survives, independent of how well the code was written. A positioning pivot (YouTube) or a generalisation pivot (Shopify) preserves the technical foundation. A product pivot (Slack, Instagram, Twitter) destroys it. Eric Ries catalogues ten types of pivot in The Lean Startup, but nearly all of them are strategic — customer segment, channel, business model, value capture.[23] Only the "technology pivot" explicitly addresses the codebase. This is a gap in the literature that the CTO should fill for themselves: before committing to a pivot, map the type of change to its expected technical impact. A customer segment pivot may require nothing more than new onboarding flows. A platform pivot may require a complete rewrite.
Yann Lechelle, a founder-CTO who navigated multiple pivots at Appsfire and Snips.ai, offers the architectural defence: "Building an architecture that isolates fundamental blocks of logic and imposes inter-process communication by way of a proper API may help migrate from a B2C product to a B2B offering that exposes those APIs to external entities. Shortcuts or sloppy execution can easily turn into technical debt which is extremely penalising in case of a pivot."[24] The CTO who built a monolith to ship faster — a rational decision at the time — will discover during a pivot that the monolith cannot be selectively salvaged. The CTO who invested in service boundaries and clean APIs will discover that some services survive the pivot and some do not, but the separation makes the triage possible.
The emotional dimension is the part nobody discusses. Nicholas Freund, co-founder of Workstream, names it directly: "When your life force has become bound in your product, it is not simple to fold your hand and move on."[25] The CTO who spent a year building a system is not evaluating the pivot objectively. They are grieving the loss of their work — and that grief can manifest as resistance to the pivot, as overconfidence that the old code can be adapted, or as paralysis in the face of a decision that requires killing what they built. The CTO who recognises this emotional dimension can manage it. The CTO who does not will mistake their attachment for architectural judgment.
The term for this — which does not exist in the literature but should — is pivot debt: technical debt created not by shortcuts or ignorance but by a change in strategic direction. It is the most expensive debt a startup can incur, because it arrives all at once and it cannot be paid down incrementally. The only question is how much of the old system can be salvaged and how much must be written off. The CTO who designed for reversibility — the subject of Chapter 4 — will salvage more. The CTO who optimised for speed without abstraction will salvage less. Both will feel the loss. The difference is whether the loss is weeks or months.
|
AUTHOR: If CorralData has pivoted — even a partial pivot, such as a shift in target customer, a change in the core product thesis, or an evolution of the AI strategy — describe what happened to the codebase. What survived? What became debt overnight? If CorralData has not pivoted, describe what a pivot would do to the current architecture — which components would survive and which would not. The reader at a healthcare startup considering a market or product change needs to see a CTO thinking through this in real time. |
When to Rewrite and When to Resist
The temptation to rewrite is the final stage of debt denial. The codebase is slow, fragile, and hostile to change. The team fantasises about starting fresh — clean architecture, modern tooling, no legacy constraints. Joel Spolsky, whose essay on the subject was cited in Chapter 4, called this "the single worst strategic mistake that any software company can make."[26] He is mostly right.
Martin Fowler offers the alternative: the strangler fig pattern. Named after the tropical vines that grow around a host tree, gradually replacing it, the pattern describes a migration strategy in which new functionality is built alongside the old system, routing traffic incrementally from old to new until the original system can be decommissioned. "Replacing a serious IT system takes a long time, and the users can’t wait for new features," Fowler writes. "Replacements seem easy to specify, but often it’s hard to figure out the details of existing behavior."[27]
Herb Caudill, analysing six software rewrite stories — Netscape (failed catastrophically), Basecamp (succeeded three times), Visual Studio Code (succeeded as a parallel product), Gmail and Inbox (mixed), FogBugz and Trello (pivot to a new product), and FreshBooks (succeeded after five years) — identifies the pattern that separates success from failure. Successful rewrites are not rewrites at all. They are new products built alongside old ones. DHH rewrote Basecamp three times, but each version was a fundamentally different product, and old versions continued to run indefinitely. Microsoft did not rewrite Visual Studio. It built VS Code — a new product that happened to serve a similar audience. The rewrites that failed — Netscape, most notably — attempted to replace an existing product feature-for-feature while the market moved on.[28]
For the startup CTO, the rewrite question usually arises at the wrong time and for the wrong reasons. The team is frustrated. The codebase is painful. The fantasy of a clean start is emotionally compelling. The business case is almost never there. A rewrite consumes six to eighteen months of engineering capacity during which no new features ship, no new customers are acquired, and the competitive window narrows. The strangler fig — replacing one module at a time, routing traffic incrementally, keeping the old system running — is slower and less satisfying. It is also the approach that companies survive.
The exception, as Stephan Schmidt observes, is the CTO hired specifically to solve a deep technical crisis: "Stop the world. Six month rewrite. Happy future."[29] That mandate is rare, and it only works when the entire organisation — board, CEO, and team — has agreed that the current system is terminal and the rewrite is the company’s primary investment for the next two quarters. Without that alignment, the rewrite becomes the project that was never finished, never delivered, and left the company with two systems instead of one.
Chapter 4 argued that every technical decision is a business decision. This chapter argues that the consequences of those decisions — the debt they create — are a business instrument. The CTO who manages debt strategically can borrow against the future to ship faster, reach a market window, or test a hypothesis that would otherwise take six months to validate. The CTO who accumulates debt unconsciously will discover, as Cunningham warned in 1992, that entire engineering organisations can be brought to a standstill under the weight of it. And the CTO whose company pivots will discover the most brutal truth about debt: code that was right for the old world becomes wrong for the new one, not because it was badly written but because the world changed.
Andrea Goulet, who founded Corgibytes to specialise in legacy code modernisation, proposes an inversion of the metaphor that is worth holding onto. Rather than thinking only about debt reduction, she argues, the CTO should think about building technical wealth: "When you resolve some debt, you’re giving yourself momentum. When you install new windows in your home, yes you’re spending a bunch of money, but then you save a hundred dollars a month on your electric bill. The same thing happens with code. Only instead of efficiency, you gain productivity that compounds over time."[30] Debt is what you owe. Wealth is what debt management produces — a codebase that accelerates the team rather than taxing it.
The next chapter is about what debt management makes possible. If the CTO has made the right technical bets (Chapter 4) and is managing the interest on those bets (this chapter), the company can do the thing that matters most: ship. Chapter 6 argues that iteration speed is the startup’s primary competitive advantage, and that the infrastructure of speed — CI/CD, feature flags, scope discipline — is the CTO’s highest-return investment. The debt framework from this chapter is the prerequisite: you cannot ship fast on a codebase that charges 50% interest on every change.