Ward Cunningham coined the “technical debt” metaphor. It sounds plausible, it might resonate with management. But it’s far from reality.
Let’s think about financial debt for a moment. How do you get indebted?
- With a financial debt it’s crystal clear when you get into it. You go to a bank and ask for money. That’s a very clear cut moment in your life.
- The amount of money you owe somebody is crystal clear to you and the creditor.
- How much you pay for a credit is crystal clear to you and the creditor. If you want to get a loan of $10,000 you’ll have to pay back more than that depending on the interest rate and the time you’ll take for repayment.
- Financial debt comes with a very specific plan for how to pay it back, the payback schedule.
- The creditor is very keen on getting his money back including full interest payment.
Martin Fowler saw the main problem with technical debt in its “crippling interest payments”:
„The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.“
But what if there was no debt at all? What if the metaphor is wrong?
Please check the above statements about financial debt against the reality of software projects:
- Do you know exactly when you get into “technical debt”? Do you go to some creditor and ask her for a time loan? (Because technical debt is about time. Time you want for doing B now instead of doing A, which would be the “right” thing to do.)
- Do you know exactly how much you’re indebted, how big the time loan is you get from some creditor? (Who is the creditor anyway? The customer, the architect, some manager?)
- Do you know how much you’re paying for the loan? Say, you got a credit of 2 days to do B now, instead of doing it later and doing A now. How much time will you spent in the future when you go back to A to do what you postponed? Will you just use 2 days or will it be 2.5 or 3 or 5 days then? You need to rebuild mental state, you need to deal with more evolved structures… So how much longer is it going to take?
- Do you know exactly how to pay back “technical debt” in the future? Do you know when you will start paying back, do you have a payback schedule?
- Does the creditor you got your time loan from have a keen interest in you paying back the debt? Does she come back to you and ask for the payback, like the customer asking for a refactoring you postponed two months ago?
Think about your answers to these questions for a moment…
I can tell you what I see in projects. I just see No for an answer. Each and every question has to be answered with No by those people usually talking about “technical debt”.
Nobody enters “technical debt” consciously, nobody knows its amount, nobody knows the costs for the loan, nobody has a payback schedule, and the creditor is not very keen to get a repayment.
“Technical debt” shares only one attribute with “financial debt”: some kind of interest – and that even being of unknown percentage. But that’s all.
That’s the reality of “technical debt”. And that’s why I say, there is no such thing as “technical debt”, because nobody treats “doing B now instead of doing ‘the right thing’ A” like a debt that has to be payed back.
It’s about addiction, stupid!
With the “technical debt” metaphor gone, what else could be more fitting?
I’m sorry, but to me there seems to be only one explanation left for what’s happening in software projects that constantly leads down the road to the brownfield. We have to face it. How projects are done is similar to how junkies live. We need to talk about addiction.
Here’s my simple layman’s definition of addiction:
A recurring behavior which favors a kick/quick win in the present over long term beneficial behavior.
And here are some attributes of addictive behavior:
- Addicts live in an illusion of control about their behavior. Before they engage in it they swear they drink just one glas or play only one Poker game. But then… there is no limit to the addictive behavior. The addictive behavior usually is associated with an inevitability and necessity that borders on a natural force: “I can’t help it, I have to do it…”
- Sooner or later addictive behavior leads to some kind of hangover. After the kick, which feels great, addicts suffer. They whine about massive headaches or money lost etc. – and this leads to very seriously meant promises to stop the addictive behavior. But of course those promises are never kept.
- Over time the detrimental effects of addictive behavior are not just acute hangovers anymore but serious health/social problems. Addictive behavior is not sustainable.
- Addicts strive for easy access to the addictive drug. They fear not having access to it. More and more of their time revolves around the addictive behavior/drug or preparing for it.
- Because so much focus is on obtaining or consuming the addictive drug, disposal of its remnants (e.g. bottles) or other garbage or keeping the household clean in general deteriorates. Addicts households are a mess.
- Addicts lie to conceal their addiction or its effects or to obtain more of the addictive drug.
- Addicts deny the state they are in and any cause-effect relationship between their decisions/behavior and their state.
- Any rational insight into the detrimental effects in the long run of the addictive behavior are not strong enough to stop it.
- Addicts refuse to accept help to free them from their addiction; they even assume others to have a problem, but not themselves.
- The addictive behavior often is not seen as such. The addiction can go undetected for a long time and look like normal behavior – including the hangovers. Because so many others are doing it, too. Think about smoking and drinking, both socially accepted addictions.
Now, what happens in software projects? At some point it’s clear A should be done to keep the development sustainable. But someone says, “No, no, we can’t do A now. We need to do B instead, because that’s what the customer/market needs most now.” A then A is postponed. Indefinitely. Instead B is done.
But is this addiction? Let’s compare software development with the attributes of addiction:
- Doesn’t software development lose control over when “the right thing in the long run” is postponed? Isn’t that done not only occasionally, but in a regular manner?
- Does software developer feel a hangover? Does postponing “the right thing in the long run” cause pain later on? Do developers seriously promise to not do it again?
- Does focusing on quick wins in the present cause long term damage? Does a codebase deteriorate because of a stream of postponements of “the right thing in the long run” up to a point where it hardly can be maintained at all?
- Does software project management make it easy to decide in favor of short term customer/market satisfaction instead of long term feasibility?
- Does a code base or a repository and a team room contain remnants of previous quick win activities which are of no use anymore today? Does garbage of all sorts pile up in code bases (e.g. misleading comments, dead code, code that no one understands anymore)?
- Does software development keep shortcuts and local/temporal optimizations hidden from customers? Does software project management hide how superficial quality is obtained by sacrificing sustainability?
- Does software project management deny the causal connection between the focus on short term results and long term problems?
- Does software development feel helpless to stop the urge to cater to customers’ short term expectations?
- Does software development refuse to accept help from literature/consultants or even inhouse sources to get back on a track towards sustainable development? Does software development accuse others of having no clue how things work and that the current behavior is inevitable?
- Do developers point to others in the industry who behave and suffer alike to explain how normal their own behavior is?
Think about your answers to these questions for a moment…
I can tell you what I see in projects. I just see Yes for an answer. Most projects need to answer Yes to the overwhelming majority of the questions.
Well, and that to me unmistakably means: The reason why software projects turn into brownfields, become unmaintainable, become hard to understand and change legacy code is addiction.
That is what the software industry has to face. To accept. To admit.
Without that no improvement is possible. It’s like with any other addiction.
Addictive drug
But what is the addictive drug, what is software development craving for? To speak of “technical addiction” would be wrong.
I think there are two sides to the addiction. Two needs seem to be the main drivers behind the addictive behavior:
- Certainty: Software development strives for certainty. It wants to tame the beast of uncertainty called customer/market. It still believes that uncertainty can be controlled somehow; you just need to try harder. The means to control uncertainty are buffers of all kinds, e.g. a plugin framework to be ready for all sorts of changes, some validation logic because you never know what data enters the system, an API to be cater to possible desktop/web/mobile clients etc.
- Connection: Software development longs for connection with the customer/market/upper management. It feels dependent on them and does everything to please them. It wants constant appreciation, a pad on the back. The flow of money must not stagnate. The means to keep the connection up is reactivity. Software development is geared towards immediate reaction to any request uttered by a money source. It gives up self-control/autonomy in order to receive constant appreciation. Software development fears to see a tear in the eye of a money source more than a vampire fears garlic.
Conclusion
“Technical debt” is a romantic metaphor. It feeds the illusion of control. But software development is out of control. It cannot control the self-inflicted deterioration of code bases. Because software development is an addict.
It suffers from “certainty and connection addiction”.
The signs of addiction are clear and here for everyone to see. We just have to overcome delusion and denial and have to admit them.
Then software development has a chance to overcome its addiction.
