Technical Debt - A catchall phrase?


April 6, 2017

Those who have driven in Bangalore know that how much tough it is to drive here especially during the peak hours @ signals like Silk Board. Everyone tries to get out of the signal as quickly as possible, not giving much importance to the shortcuts we take, like the wrong side, overtaking from left etc.

We complain about how tough it is to drive in Bangalore and the question that can be asked is how much we contribute to it or how much we try to correct it?

This is similar to the excuse we've for Technical Debt. The code is anyways messy, adding one more is not going to make any different. It was like this when I joined the project. We had time pressures so had to release it faster.

And this thought process ends up creating the Vicious cycle as follows:

image alt text

And this is the beginning of the so-called Technical Debt.

image alt text

And there is one more term that we all like to complain - Legacy Code. Below is one of the best definitions of legacy code I've ever seen.

image alt text

Let's look at some examples of what we call as Technical Debt.

image alt text

image alt text


The following is commonly seen - Ignoring Exceptions

image alt text

image alt text

And other common examples which I've not covered are:

I am sure all of us seen variations of all these.

What is Technical Debt

Let's take a step back and look at what Wikipedia has to say about Technical debt:

Technical debt can be compared to monetary debt. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward.

And this is what Ward Cunningham, the person who coined the metaphor, also seemed to have in mind while he coined the term.

To summarise, it is not a license to create an architecture as follows, nor the license to create crappy code.

image alt text

If we all agree that the above flaw is not considered as professional in other engineering streams, the same rule is applicable to Software Engineering too.

As prudent professionals, it is our responsibility to follow the four rules of simple design:

And this includes the following:

Technical Debt Quadrant

Going back to the definition of Technical Debt by Wikipedia, it should be a result of a conscious, thoughtful and prudent decision than that of an unconscious one.

Martin Fowler uses a quadrant to explain similar concepts where he points out that it is not useful to discuss whether something is a debt or not, better ask whether it is reckless or prudent. The more the issues/flows are in the Prudent section, better it is.

image alt text

Paying down Technical Debt

Every team will have technical debt, and it is normal because we learn with our products continuously so it is ideal to have prudent debts.

Another thing is that not all of them needs-pay off. Some of them might be in those areas where we hardly make changes.

So how to identify what needs-payoff? I would like to quote Henrik Kniberg here:

What is technical debt anyway? Anything about your code & development environment that slows you down. For example:

And pay off them with:


Following are some of the highly recommend books for improving the code quality and cleanliness:

Clean Code


Growing Object Oriented Software - Guided by Tests [known as the GOOS book]

The following are some of the articles/talks on the same subject:

Building a Culture of Code Quality - Bryan Helmkamp

The Technical Debt Trap - Doc Norton

Why do teams fail to sustain code quality?

A mess is not a technical debt - Uncle Bob

Debt Metaphor - Ward Cunningham

Technical Debt Quadrant - Martin Fowler

Sacrificial Architecture - Martin Fowler

The solution to technical debt - Henrik Kniberg

I Shall Call It.. SomethingManager - Jeff Atwood