What is technical debt? And how to talk about it?

Title slide

The metaphor

Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying off in the future. A mess is always a loss.

Given a strong motivation, developers have three choices: redesign the work, distort the system (for instance, by ignoring defects), or cheat and game the system. And so if developers do not have the know-how to redesign the system, they are left with two options: distort or game the system.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

The origin of the Metaphor

[A] serious pitfall is the failure to consolidate.

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation[…].

[to rush] software out the door to get some experience [is] a good idea, but […] of course, as you learn things about that software, you would eventually go back and repay that loan by refactoring the program to reflect [your accumulated learnings].

[Some] people would rush software out the door and learn things, but never put that learning back into the program, and that by analogy, were borrowing money thinking that they never had to pay it back. Of course, if you do that with your credit card, eventually all your income goes to interest and your purchasing power goes to zero.

We ❤️ agile ways of working

We are designing an entire system of delivery, from idea to end user, around the truth that every requirement is wrong, we’ve misunderstood it, and/or it will have changed by the time we can deliver a solution for it. The longer the delay between request and delivery, the more expensive that problem becomes.
–Brian Finster

The biggest cause of failure in software-intensive systems is not technical failure; it’s building the wrong thing.
–Mary Poppendieck

Move fast, but…

Mark Zuckerberg, standing in front of a screen saying “Move fast and break things”.

Move fast, and… The DevOps answer

For six years in a row, however, our research has consistently shown that speed and stability are outcomes that enable each other.

Mark Zuckerberg, in 2014, standing in front of a screen saying “Move fast with stable infra”. Credits: Mike Isaac

A better definition of Technical Debt

A graph showing value over time. Simple interest grows value linearly over time. Compounded interest grows value exponentially over time.

…but why are we taking on debt?

Process Performance, a system thinking view

Working Harder

Working Smarter

Reinvestment Loop

Shortcuts Loop

System response

The Capability Trap

The Fundamental Attribution Error

Self-Confirming Attribution Error

So what?

“What got us here won’t get us there”

Visibility

Technical Debt has come to mean just about anything that technologists believe requires an investment whose value is not obvious to the rest of the business. [It’s like saying] to the CFO “these are the things you’ll never understand but have to give us money or allocate time for.

Flow Framework

I’ve found the Flow Framework to be incredibly useful for describing the finite ways that engineers spend time and the consequences of not addressing tech debt.

A better metaphor to communicate: “Technical Delta”

Summary

Make all work to be done visible.

But agility is not about being productive, agility is about learning fast that you’ve been building the wrong thing.

Cutting scope and meeting the deadline is almost always the best approach.
–Mary Poppendieck

Sources

More resources

System thinking

Technical debt

Visibility & flow

--

--

50% system manager at Akeneo / 50% endurance cyclist. Will train for food and burn it for adventures.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store