The two dimensions of Technical Debt

Technical Debt is a powerful concept, first described by that name by Ward Cunningham in 1992.  It is readily understood and easily communicated.  It’s useful even to a non-technical audience, because we all broadly understand about financial debt (or believe that we do). However, Technical Debt is still significantly misunderstood. 

As argued by Cunningham, as soon as you deliver your first code, you have a set of implied commitments.  From that point, the code which you have shipped will incur an on-going cost.  Effectively you have incurred a “debt” from releasing that code. It’s worth noting that Cunningham’s view of “debt” was not as negative as people might expect. He worked in a finance company and saw carefully managed debt as potentially an asset.

In monetary debt, you borrow money and you pay interest.  The analogy with software is that once you release code, you must maintain it. 

All the work you do to maintain the code counts as “interest” on that debt.  Ideally, the code would be perfect and would never need to be looked at again.  In reality we make compromises and introduce imperfections during development.  Each of these will have a cost in the future. 

Cunningham saw this as a conscious trade-off.  We could choose to achieve a business opportunity or create an early prototype.  But if we did this we would have to accept that this resulted in poor code.  We had “borrowed” to accelerate the schedule and would have to “pay back” later. In a financial view, he saw this as an essential engine in driving development, in the same way as credit in an economy.

Types of Technical Debt

Technical debt may come from many different sources. Conscious decisions are made to take short cuts, errors are introduced accidentally, better solutions become apparent from later learning, new good practices become available, opportunities to simplify appear as the product grows and evolves. 

If we fail to address these, the product becomes inflexible or fragile.  We typically see this in longer development times, increased support burden and rework.  This is the “interest” paid in the Technical Debt metaphor.

Martin Fowler introduced a model for Technical Debt to look at the different types of debt we might incur.  In his model he categorises Technical Debt into causes which are deliberate and those which are inadvertent.  In the other dimension he categorises them as reckless or prudent.

Using this model we might find that Technical Debt has been introduced inadvertently.  This could be through recklessness, for example being unaware of basic design principles or by rushing ahead without thinking about design.  Alternatively it could be prudence, for example exploring a new technology area expecting and managing learning. In this case we lack knowledge, but we are aware we lack knowledge and plan future action as a result.

In the other dimension we might deliberately introduce Technical Debt.  This again could be reckless, for example deciding we will discard design and rush ahead with coding.  Or it could be prudent, deciding to deliver for a key opportunity and come back and deal later with the consequences. 

Technical Debt is often seen as wholly a bad thing. However, remember that Cunningham saw Technical Debt as an opportunity as much as a threat. In Fowler’s model we should try and ensure we adopt Technical Debt deliberately not inadvertently.  We should consider the implications of maintaining and developing the code that we develop. 

Good Practices

You should ensure the organization understands addressing technical debt.

We should also make sure we adopt Technical Debt prudently when we do so.  When we do realise we are accruing debt we should do so with a plan to address that debt.  The most critical factor of managing technical debt is to ensure that we plan to address the debt. 

Sometimes this plan may be through significant organizational programmes.  We might choose to address a specific part of the product which has become slow or inflexible.  It is not unusual for example for an organization to outgrow its original build system.  Significant refactoring may be needed in order to deal with increased build complexity and resulting lower speed.

Much technical debt reduction is a much more minor activity.  This is often managed through the retrospective process.  The team are best placed to see the areas of existing code which are slowing them.  They can identify these through retrospectives and put corrective actions on the backlog. 

In some cases technical debt may also be highlighted and reviewed in a Sprint Review.  This is likely to be where it relates specifically to new code.  Code may be under-performing or a better approach realised during development.  The Sprint Review would be a good place to discuss a conscious decision on prioritising rework.

Above all ensure that we do not generate unnecessary complexity which will be hard to maintain. Put in the effort to write good code from the start. Allow the time to refactor old code as you go along to take account of changes and learning. Invest in good automated testing. Technical debt reduction is best managed as a continuous improvement process.

Simplicity–the art of maximizing the amount of work not done–is essential
Principles of the Agile Manifesto