The True Meaning of Technical Debt

 

Sign up for our newsletter on globalization and localization matters.

 

Last week I came across this old article by Rands about managementese.

It’s a great essay on communication — and how, in the workplace, communication naturally optimizes for clarity and speed.

Weird phrases that we often mock, such as "action item", or "circling back", are actually highly efficient vectors of meaning. They fit non trivial concepts in very few words, and are understood by everybody.

One of such great metaphors is Technical Debt.

Technical Debt is widely used and discussed within engineering teams. It’s a successful concept, I believe for a couple of reasons:

• It's intuitive and backed by common sense — something that piles up and makes you slower and slower, just like interest on existing debt.

• Management understands it, yet it stays under control of engineering.

These elements make it a perfect leverage when negotiating priorities, deadlines and resources.

However, is it really as clear as it sounds?

It is a fact that, over time, all development teams get slowed down by the existing codebase. But why? Is it because maintenance is inevitable? Or because we could do something better in the first place? Or both?

Why Technical Debt Happens?

If you search for "Technical Debt" on Google and look at excerpts from the first page, you will find some kind of consensus.

 

It looks like it is something that accumulates because of some nasty, dirty practices. If true, it should follow that by writing clean code from the start (and documentation, and tests, etc.), debt never piles up, or it does in a negligible quantity.

Of course, if you have any experience working in an engineering team, you know this is false.

Technical debt creeps in even when you work with the best intentions, and follow the very best practices.

But why?

Technical Debt as disagreement

Enter this short video by Ward Cunnigham.

 

Ward is the original inventor of the "Technical Debt" term, and it's revealing to hear the sentence in which this metaphor was used the first time (emphases are mine):

If we fail to make the program aligned with what we understand to be the proper way to think about our [...] objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.

Ward describes debt as the natural result of writing code about something we don't have a proper understanding of. He doesn't talk of poor code — which he says accounts for a very minor share of debt. He talks of disagreement between business needs and how the software has been written.

But how do we land to such disagreement? In my experience, there are two offenders:

Wrong Design — what we built was wrong from the start!

Rapid Evolution — we built the right thing, but the landscape changed quickly and made it obsolete. Let's see both more in detail.

Let's see both more in detail.

Wrong Design

It may happen that the team designs a solution that doesn't properly fit business requirements, in a non-obvious way.

Requirements may still be met on the surface, but something is wrong under the hood — an abstraction that doesn't fit, some duplication, scalability issues, and so on.

Of course, such things may happen because of poor development skills. But in my experience, most of the times it's because developers didn't fully understand what had to be done.

How to improve?

If this happens regularly, a natural response is to invest more in the design phase. This means, of course, more engineering analysis, but also more talking with stakeholders. You should discuss both the here and now, and the future evolution of the project.

If this happens regularly, a natural response is to invest more in the design phase. This means, of course, more engineering analysis, but also more talking with stakeholders. You should discuss both the here and now, and the future evolution of the project.

Increasing Design effort brings diminishing results after a while, so it's up to you to find the sweet spot, based on how solid is your company planning vs how much change you can expect in the future.

Rapid Evolution

The second scenario is when things change so rapidly, that today's requirements cannot really be trusted.

That is: even if we build the right thing, it risks becoming obsolete fast, because of the ever-changing business landscape.

How to improve? 

A thorough Design phase provides limited protection against future changes, so a leaner cycle might work better:

1. Rush — the code out of the door

2. Learn — more things about your business reality

3. Refactor — put that learning back into the software

Basically, we take a piece of the Design effort and move it forward, in a Refactoring phase that happens every time a few pieces have consolidated and are ready to be secured.

In this scenario, we are accepting the creation of debt, trusting our ability to repay it in the short term.

This ability comes down to three elements:

• Writing code that is clean to refactor — which is very different from clean. Such code is similar to those sailor knots who should be strong enough to hold for a while, but easy to dismantle when not needed anymore.

• Actually learning along the way — analyze, with the help of stakeholders, what still fits and what is going to become debt.

• Spending regular time on refactoring — reorganize the code periodically to reflect your updated understanding. This is easy to dismiss, letting the debt pile up until it’s too late and you need a big rewrite. Taking baby steps every time is more sustainable both for your business, and your development team.

Takeaways

As always, I try to summarize the main points of the article in this final section.

This should be useful for the reader, but it is also a reality check for me to understand if what I have written makes sense from top to bottom.

So, if you are in a hurry, that's what you should remember:

1. Technical debt is caused by a lack of understanding — it stems from disagreement between business needs and how the software has been written.

2. You can limit such disagreement... — by spending more effort on the design phase, and by properly discussing requirements with stakeholders.

3. ...or you can embrace it — by explicitly planning for lean releases and following rework. This is a better choice when the future is uncertain and might bring radical changes.

Resources

A few resources that helped me write this article, and can be useful to dig deeper into this topic:

• Debt Metaphor — a short video by Ward Cunningham that explains the relationship between debt and understanding.

• Technical Debt as a Lack of Understanding — a recent article by Dave Rupert that reflects on Ward's definition and adds up valuable real world experience.

• Technical Debt Quadrant — a thoughtful essay by Martin Fowler about what Technical Debt really is, and its different types.

•  Managementese — a great article by Rands about management speak and communication in the office.

 

Do you want to contribute with an article, a blog post or a webinar?

We’re always on the lookout for informative, useful and well-researched content relative to our industry.

Write to us.