While technical debt sounds like it has to do primarily with the technology group, systems thinking gives us another perspective. One needs to look at technical debt from an holistic point of view.

One of the reasons why organizations accrue technical debt quickly is that they don’t see it as a systemic problem. It’s a problem with a component, the code, embedded within the larger system, the human and technological apparatus that builds and delivers software value. When brave and noble souls who want to clean up or prevent debt encounter resistance to the idea, they’re usually arguing with someone who has taken only the very limited perspective of the code and the developers who create it.

Sure, technical debt makes it harder to write new code or fix the existing code. Yes, a debt-ridden code base can make the job horrible, reducing team morale, productivity, and commitment. Nonetheless, the person who doesn’t want to invest in technical debt reduction or prevention thinks the price is worth getting to market faster, clearing out an impossibly large backlog, or just keeping the Corporate Masters happy with the perceived pace of work.

Technical debt has real Business costs

The most immediate cost of technical debt, which you see when you run a static analysis of the code, trace the gradual increase in the average size of work items, is often not persuasive enough to get people to address it. The more frightening impact of technical debt happens at a larger system level, something that you can’t ascertain from measures like cyclomatic complexity or velocity. Here are a few examples:

• Unreliable plans. The greater the technical debt, the harder it is to create reliable plans. Not only does technical debt make it harder to code than it should be, it also makes it harder to know how much extra effort will be needed. Gradually, estimates become less reliable – and so, too, do the plans based on those estimates.
• Lost customer good will. Technical debt makes it harder to meet customer demands with new functionality. It also complicates efforts to fix issues, putting customer patience at risk.
• Fewer portfolio options. Once technical debt reaches a certain level, organizations find it harder to manage projects or products at the portfolio level. A lower-value project might need more people to keep it on life support. The people who really understand the code, often because they created a lot of the technical debt in the first place, can’t move on to other work.
• Lost market opportunities. When a new opportunity arises, such as expanding operations into new markets, the last thing executives want to hear is that some required code components are going to slow down that new endeavor.
• Company valuation. One of the nasty surprises that software companies face is, yes, technical debt does affect your company valuation when someone wants to acquire you. Code quality can become a sticking point in an acquisition, for both small start-ups as well as established vendors.

The Business is often to blame for technical debt

These are real costs that exist at a system level that you don’t see by looking at the code. The system level is also where many of the root causes of technical debt reside. It’s easy to blame the teams, or individuals on the teams, for their purported inexperience, unprofessionalism, or sloppiness. However, the real sources frequently lie elsewhere. Here are a few common culprits:

• Hyper-demand. Many teams are working way over their capacity. The business’ inability to prioritize, or make other hard decisions, means that software teams have to cut corners in order to keep pace with the demand for their work.
• Short-term business thinking. The business often thinks in very short time horizons, driven by quarterly results and other concerns. That thinking leads to pressures on software teams to deliver something that achieves short-term results, without regard to long-term consequences.
• Ignorance and distrust of how software professionals work. People outside of the development team generally don’t understand how software development works, and they don’t care. However, their ignorance has consequences, leading to statements like, “The prototype looks good – why don’t we just ship it?” When the people making these statements don’t trust software professionals, they will be deaf to their objections.

Technical debt is often beyond a purely Agile solution

Because the real causes and consequences of technical debt exist outside of the team, it’s not surprising that Agile alone hasn’t immunized teams against technical debt. To diagnose the problem, prescribe possible solutions, and assess their effectiveness, you need a broader, system-level perspective, which Lean provides. Flow, waste, value – these concepts are closer to the business causes and costs of technical debt than the Agile lexicon can describe.