Resources on why managing tech debt is important?

Does someone know some good articles/blog post/talks (not books) about why it is important to manage/reduce technical debt? Preferably something that is understandable for non-engineers (product managers, designers, UX reseachers).

At work we often talk about explaining the why for the work we do (e.g. when we present in a demo meeting) but I feel for the tech debt work, it is not exactly that every individual ticket has a very specific effect. It is more about the big picture of keeping tech debt in check. I know many reasons besides velocity why doing this work is important in a product company but I wonder whether someone can recommend a resource that expresses it nicely.


Alternative strategy: answer the question «What is technical debt?»

I reckon once this is clear, it’ll be obvious why its management is important.

(Still left to explain: that you really are managing technical debt.)

I’d search hackernews and read the top 10 submissions, I’m sure you’ll find something useful: HN Search powered by Algolia
From glancing at the search result, Martin Fowler seems like a good source, he also links to two other articles of his on technical debt.

I think it’s mostly about explaining to people why a certain debt has been slowing you down (or why you expect that it will slow you down for upcoming task X) and how you are addressing it so future development will be faster again.


I share the view expressed in this article that technical debt is to be expected in almost any project and that it only makes sense to work on it if it slows you down:

You can have areas of your application that have significant portions of technical debt for years and still not actually negatively harm the business or product. This is simply because those areas don’t change often, and therefore don’t actually harm development against them. This is why in large companies you often see services with older language code that has been untouched for years.

Fowler considers taking up technical debt often not even worth in the first place in his Design Stamina Hypothesis article.

When your delivery is above the design payoff line neglecting design always makes you ship later. In technical debt terms it’s like taking out a loan but not using the principal for so long that by the time you use it you’ve paid out more in interest payments.
This raises the question of where that line is. […] I take the view that it’s much lower than most people think: usually weeks not months. But again this can only be a judgment call.

For me this goes too much into the direction of predicting the future and future requirements, which, like measuring productivity, we can’t reliably do. YAGNI and all that. But it will always be a judgment call. Some design decisions obviously have more weight to them than others. (see Data Structures in the article by Shaun McCormick)

I’m also reminded of this quote from Kent Beck’s book Refactoring:

In almost all cases, I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts. You don’t decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing.

While fixing a flawed design might not be possible to do in small incremental steps, I think working on technical debt should always serve the clear goal of making certain future changes easier.


Katrina recommends YOW! Conference 2017 - Doc Norton - The Technical Debt Trap #YOW - YouTube - I’ve not watched it personally.


Thanks for the question @junedev - really got me thinking about this issue from the non-technical side of things and what I’d need to get a clear picture of the importance of addressing technical debt.

As such I’ve created a new post to explore this from a wider angle so as not to derail the conversation and lead it astray into wonderful, but off-topic issues!

My goal is to widen the conversation and ultimately help us as a technical community, understand the issue in depth…thereby providing a key resource for the future perhaps…

I’ve been reading and really enjoying Chelsea Troys blog lately and she has an interesting blog series on Technical Debt: Quantifying Technical Debt – Chelsea Troy. She also has a series on How to Socialize Big Changes at Work, Part 1: Start at the Grassroots Level – Chelsea Troy.

1 Like

I refer back to the originator of the phrase, Ward Cunningham:
“Shipping first-time code is like going into debt. A little debt speeds development so
long as it is paid back promptly with refactoring. The danger occurs when the debt is
not repaid. Every minute spent on code that is not quite right for the programming task
of the moment2 counts as interest on that debt."

I grabbed that from this pdf - Introduction to the Technical Debt Concept

Ward also has a short video on his definition - Ward Cunningham’s Technical Debt Metaphor


I just saw this on LinkedIn, which while not an amazing resource might be a good feature in explaining things via a visual metaphor! David Bland on LinkedIn: "Siri, what is technical debt?" | 71 comments

Watched this, and it was great food for thought indeed, thanks for sharing.

1 Like