I’ve seen many different definitions of technical debt (as it applies to software), but most of them are very specific and indeed often tied to some kind of technical debt metrics dashboard that vendor X is selling.
So when a co-worker asked me to define it a few days ago, I thought I’d better come up with something a bit more useful.
For me, “technical debt” is the long-term price companies pay for adding functionality and features hackily, i.e. without really thinking about how those changes impact architecture, documentation, usability, clarity, maintainability, etc. When the things that come back to bite you actually do bite you, you’re paying interest on your technical debt (i.e. you only pay it off completely if you can get rid of it).
Hence to assess your company’s current level of technical debt, you need to assess what proportion of work time a typical engineer spends actually working productively, as compared to performing other ancillary work-time activities that relate to dancing around the accumulated mountain of hacks and increments that it (perhaps laughably) calls its codebase.
Such unproductive activities include:-
* Finding, reading and understanding informal documentation (often left abandoned on internal Wikis)
* Working out how to add new workarounds to work around the current set of abandoned workarounds
* Spending time in meetings with other engineers trying to convince them that changing old code is a good idea
* Fixing regression failures that just happen to reveal old bugs that had previously been untested by unit tests
* Following arcane coding standards that have not been updated to reflect current tools and practices
* Reinventing software wheels because of policies that prohibit code reuse outside formal APIs
* Using log files to debug full stack builds (because they have become too complicated to use gdb etc)
* And so on.
The problem is that as a company’s technical debt reaches 80% or so, the company becomes largely paralyzed: while having a technical debt of 90% is close to terminal, with each engineer having on average only 6 minutes out of each hour being applied productively. Few companies can sustain this level of burden for long without collapsing.
What is not widely understood is that this isn’t just a feature of large companies with old applications. With their explicit reliance on incrementalism, Agile companies too can exhibit all of these problems if they have no engineers with architectural flair or no time explicitly put aside for refactoring. (The “Lean Startup” is no different.)
All in all, high technical debt can be a crushingly huge problem – how high is your company’s level of technical debt? Can you honestly say that it’s less than 50%?