Technical Debt is Agile Debt
Today, under the term “technical debt,” we conceal one of the greatest follies of contemporary software development. The causes are layered: they range from simple misunderstandings of the term to a lack of responsibility to cargo-cult agility.
In this post, I’ll start with the misunderstanding: What is technical debt in agile software development?
With my clients, I mostly encounter the following understanding of the term: Technical debt is a deliberately accepted shortcoming in software that is either not visible externally or only to a limited degree. This primarily includes shortcomings at the code level that are fixed later (paying off the debt). Developers who value clean code don’t want technical debt in their codebase. Technical debt is accepted, for example, to implement a large new feature in a sprint, even though doing it cleanly would take longer. Quick & dirty, basically.
But this explanation doesn’t match the original meaning. In a video from 2009, Ward Cunningham—the person who coined the term—explains what he originally meant and how it came about. If you listen closely, you’ll notice that Cunningham used the word “debt” in a project where the team was developing financial software. He spoke of “debt” to use a term the client would understand, and because he believed it was a good metaphor in the financial context.
From today’s perspective, I actually think the metaphor is completely inappropriate—it now contributes to serious problems. Cunningham considers the idea of deliberately writing code worse than you’re capable of as completely absurd. I agree with him. So if that’s not what he meant, what did he mean?
In agile development, software is written (as well as possible!) based on the current understanding of the problem and requirements. Both can change rapidly in an agile environment—sometimes after just one iteration. Maybe because the client changed their mind. Maybe the market shifted. Maybe stakeholders gave surprising feedback.
Whatever the reason, the software from the previous iteration may no longer be the optimal solution for the new situation. The gap between the current state of the software and the new understanding of the problem is what Cunningham called debt. But this debt is not technical in nature—it stems purely from the incomplete understanding of the problem, which is inherent in complex, agile development.
And it’s not debt you take on consciously. While writing the code, you believe you’re building the software properly. Why wouldn’t you? Otherwise, concepts like Continuous Delivery would be total nonsense. Who wants to ship product increments regularly that contain deliberate technical flaws? Anyone who consciously produces poor quality is certainly not acting in the spirit of agile.
Worse yet: if your understanding of the problem changes (e.g., after a sprint), it becomes absolutely essential that the code is as “clean” as possible—free from what we now call technical debt. Because if you’ve already written the software worse than you’re capable of, then after a sprint you’ll not only be facing a new understanding of the problem, but also fighting against your own legacy code.
In this way, technical debt becomes a burden on agility and—if left unchecked—leads to technical bankruptcy: a state in which it’s cheaper to rebuild the software from scratch than to refactor the debt-laden system. Tear down and rebuild.
For what Cunningham originally meant, I propose the term Agile Course Correction. I think of it as similar to navigating a sailboat. Without going into detail: there are many factors that can influence a boat’s course—wind, currents, compass deviation. By determining your position, you can identify deviations and correct your course. I find that to be an excellent metaphor for agile development.
What can the development team do to prevent technical debt?
This question deserves more space than I can give in a single blog post. So this topic will certainly come up again here in the future. Still, I’d like to briefly touch on it.
First of all, dominant stakeholders or patriarchal product owners, team leads, etc., who pressure the team to quickly develop new features, take on new technical debt, or leave legacy issues unresolved, create ideal conditions for turning technical debt into technical bankruptcy. The development team holds the responsibility here—no one knows the scope of the technical baggage better than they do.
If you work on a team your boss claims is agile, then in my opinion, you have the right to participate in decisions and bear responsibility. One key way to exercise that right and responsibility can be summed up in one word: No. Meaning: if I, as a developer or team, realize that someone is asking for something unreasonable, “No” is the right answer.
And what if the story really is too big for a sprint?
I’ve seen teams shamelessly put tickets like the following into their backlog:
“Big Feature, Part 1”
“Big Feature, Part 2”
“Big Feature, Part 3”
“Big Feature, Part 4”
“Big Feature, Part 5”
…and so on.
Each ticket matched the workload of one developer for one sprint. When I asked how many parts the feature would ultimately have, I got the answer: “We don’t know yet—we work agile.” It’s worth noting that all these tickets had gone through refinement and planning.
Anyone who has read this far will agree that such an approach has nothing to do with proper agile practice—or even traditional plan-driven approaches.
What was missing here was at least an attempt at expert-level story splitting. I consider story splitting to be an art that very few teams actually practice. Most give up too soon and fall back on mantras like “It can’t be done any other way,” “You can’t make this smaller,” “The feature is just that big,” or “If you make it smaller, there’s no more value.”
My clear advice at this point: If a ticket doesn’t fit into the sprint—
clarify what delivering value means to you,
practice story splitting
do not take on technical debt.
In conclusion: One thing technical debt does have in common with financial debt: in most cases, it’s best to pay it off quickly.
But unlike financial debt, I doubt that technical debt has any real benefit in agile development. If you keep taking it on, it’s a sign of a problem somewhere else.
This article was originally published on heise.de in the german version.
https://www.heise.de/blog/Technische-Schulden-sind-agile-Schulden-8986851.html