Technical debt is not the result of bad decisions!

(This post has originally been published on LinkedIn and has been cross-posted here for conservation and accessibility. It has been auto-translated from German and human-reviewed.)

❌ Technical debt is not the result of bad decisions!

I came across this slide last week at Fluttercon/Droidcon in Berlin, and I think it proves once again that the concept of technical debt is seldom well understood, and even more rarely communicated well.

Taking on debt in software engineering — just like in real life — can be a conscious, strategic decision. Debt is not automatically a mistake. And it doesn’t ruin a project either.

On the contrary: Many successful products and companies simply wouldn’t exist today if they hadn’t taken a shortcut or two in the past. Nobody needs a perfect product in two years. But everyone needs a working product today.

That’s why technical debt is, first and foremost, inherently neutral. What really matters is how we handle it:

• 💰 Are we fully aware of the future costs?
• 📈 Do we just let the debt sit there until the compounding interest of maintenance crushes us?
• 💪 Or do we keep track of our open balances — and regularly pay them down?

Only by actively tackling legacy issues do you create the breathing room to take a new shortcut when you need one. 👣

✅ Therefore, technical debt becoming a problem is the result of unsustainable management!

Sometimes, though, I wonder if I’m being too idealistic about this and if the code purists might actually have a point after all.

What’s your take on this?