Defining Technical Debt

Every leader in the Technology area (IT, Software Dev, etc) faces at some point the challenge of understanding and managing Technical Debt. So you better have a good definition and approach for it.

In this article I’ll focus on defining Technical Debt, in a subsequent one I’ll focus on an approach to manage it.

What it isn’t

Defining Technical Debt is not a simple task. Let me start by disagreeing with the most common definitions of tech debt.

Definitions like “In software development, technical debt […] is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.” [source] or “Technical debt […] describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.” [source].

I do not agree with definitions like these for a couple reasons:

• Because they imply that there is a correct way to do things. I wish that was the case, but a solution that is perfectly fit for the needs of the business today, may well become inadequate in the future as the needs of the business evolve.
• Because there IS a place and time for hack-ish, scrappy, throw-away code too. In a Lean organisation, when doing discovery you want to learn as fast and cheaply as possible. At that time, not caring about performance, or scalability, or even whether the experience is smooth, might be the right call. The problem comes later if you want to run a business based on a hack and don’t take the time to implement a system that will properly sustain the business. But be clear, how much you should invest in the system is directly tied to the value you expect from it.
• But most importantly, because, in my experience, when I’ve heard people use this argument, it’s because they are trying to create a separation between who defines what to do (the space of the Product Manager), and who defines how to do it (the space of Engineering), and use that as an excuse to abdicate responsibility (e.g. “I was forced to deliver it in an impossible timeframe”). While certainly these are two different skills that come together in the process of delivering value, defining the “what” and the “how” must be a collaborative process. I’m the CTO, so I’ll talk to the engineer: you should get to a place of comfort taking on Technical debt. You should embrace the deadlines you’re working towards, and you should explain the tradeoffs that are being made. If you’re not being heard, speak louder, and if necessary escalate to your VP Engineering or CTO.

Regardless of these issues with its definition, the term Technical Debt has worked well because, it does explain well some of its most important characteristics:

• It compounds with time: If you don’t repay sufficiently it’ll grow exponentially,
• Just like with financial debt, having some is a good thing because it can serve as leverage to grow the business (push cost to the future),
• And, also like with financial debt, there’s no problem in having some, but you better manage it properly and stay on top of it, or it’ll end up costing you the house.

Also, it’s a familiar concept when discussing it with CFOs and CEOs :)

What is Technical Debt?

Ok. Enough of what it isn’t…. What IS technical debt?:

Technical debt is the drag that software systems impose on the business.

And there’s many ways in which this drag is experienced:

• System not being fit for purpose: It does not reflect and support the actual processes that the people of the organisation execute, therefore there’s a need to translate data going in and out of the systems, and manual workarounds. E.g. export to Excel, do some processing and upload again [shivers]
• System not being easy to change: Either because the people that built it have left the org, or because its complexity is poorly managed. E.g. you’re afraid to make changes to it.
• System doesn’t fit the org structure (Conway’s Law): It doesn’t play well with the organisational structure of the company. E.g. Doing any change in this system requires coordination with 3 other teams in different business units with disjointed prioritisation processes,
• System has low quality (functional requirements): The outputs of the system have errors that require human intervention to correct, or worse still, people stopped trusting the outputs of the system.
• System has low quality (non-functional requirements): The system breaks frequently, people are routinely woken up at night, does not scale to support the business, or is too costly to maintain (in terms of either $ or toil).

This definition talks to the “why” managing and paying Tech Debt might be a good idea, and sets the foundation for the framework we use to tackle it.

In a future article, I’ll share a framework to understand, manage and prioritise Technical Debt. Stay tuned.