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.

„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.

I'm glad you're mentioning it: Yes, there are a lot of people (private households) who get into financial debt without much thinking about. And why is that so? Well, it's another kind of addiction. (Albeit a very difficult one to detect because it is so commonly accepted. It's almost the foundation of the western/american way of life.)

Does Ward Cunningham have thought about these kind of debtors? Very unlikely. He would have mentioned that in his explanation. But maybe you want to ask him.

As for the strawman: Well, since I don't know any kind of description of attributes of financial debt in the context of "technical debt", I think my approach is more substantial. I'm at least trying to lay a foundation one can argue about.

So do you want to provide a better description of how financial debt is incurred by companies on a regular basis? And then match your description to how legacy code "happens". Please go ahead and share a link to your explanation.

As an SEO expert, I admire your link bait skills, but I think you actually also believe your argument, so I'll bite. Mind you, I have no vested interest in the term "technical debt", but, even in your own description of your choice for a more appropriate term, you describe things that remind me of "debt", which I could argue is "something you owe later for something you get now". I could also argue that "debt" signifies to me "something that limits your future choices", "something you must pay back at some point". In fact, as Ward himself explained, technical debt, similar to financial debt, is not always a horrible thing when you go in with eyes wide open. When will being an addict help move a project forward? If you really are serious about this and not just working on your link bait skills, reconsider the "metaphor" aspect of the two terms. Do you really think it would help a layman understand the implications of doing B now instead of doing A by saying, "well, that will make us a junkie" as opposed to, "well, we will incur some technical debt". I think your argument about development's search for control and our addict like behavior is actually decent but it does not discount everything we've come to understand about technical debt. If anything you've just described the irresponsible side of dealing with technical debt. Of course, this is just my opinion.

Sure, "technical debt" seems to be intuitively meaningful - but so was blood letting. Unfortunately blood letting did not help; it was based on the wrong physiological model.

The same for seems true with "technical debt". People talk about it, they find the metaphor fitting - but nothing much changes. As I tried to make clear by listing the attributes of financial debt: almost none of them can be found in technical debt. That way it's no small wonder so little changes in terms of avoiding code base deterioration.

But with the addiction metaphor it's easy to explain.

So it's all a matter of model. Models are supposed to help understand the world and point at how to improve its state. The model behind blood letting did not help much. The current model we have now seems to be better - while not being perfect.

When I look at software projects I don't see rational behavior towards incurring debt. What I see is irrational behavior. What I see is denial. What I see is action contrary to insight. What I see is hope despite evidence to the contrary. What I see is procrastination. What I see is heaps of dirt.

Of course any addict incurs a debt. Being an alcohol addict you can have "fun" now - and pay later. Maybe your currency is "intensity": twice the intensity now is maybe only a third intensity tomorrow or in 10 years from now. Or even less.

"Live fast, die young" is a legitimate way of life. As is piling up dirt in your code as you go. Addictions of any kind are a matter of personal economics.

Also incurring debt is not horrible per se. A loan is a means to achieve some goal. That's fine. And as long as you use it wisely and have a choice, all's well.

But that's not happening on a large scale in software development.

Of course being an addict does not help - in the long run. Nevertheless people are addicts everywhere and in many regards. That's my point. Despite the long term bad effects people do the wrong things. They can't help it. They are, well, addicted to quick wins, the kick, the temporary optimization of their feelings.

Nobody says, "Well, that makes me a junkie". Again, that's my point. Junkies have hardly an insight into what they are. Or if they have, it doesn't make a difference. They same is true for many software projects. Nobody wanted to become addicted - but they are. Because they cannot help it. They feel driven to do the things which are bad for them in the long term. And they deny it. And they try to explain it away. And sometimes they solemnly promise to do better - but then don't.

(By the way that's not just how it's with software projects. It's a pattern you can see in all sorts of businesses/companies. But that's a different matter.)

Addiction is of course irresponsibly incurring more and more debt. But to talk with a junkie about debt is of no use. This is my point. The "technical debt" metaphor suggests we can approach the matter rationally. Just increase insight and things will change. But is hasn't worked in the past years.

So what I'm arguing for is to change the approach. We need a more therapeutic approach towards the heaps of dirt in code bases. This does not sound attractive, I know. But I don't see any other way. We need to become honest: we don't really control it. We are controlled by the need to achieve short term benefits and stave off uncertainty.

Only when we start to be honest about having lost control and being addicted we can start to turn around. And then... maybe some day the debt metaphor might make sense.

I think the term "technical debt" is here to stay, but I do see some value in relating it to an addiction. However, I wouldn't compare drug addictions to years of brownfield design and software. To me it’s more like a "hoarder”. These humans stockpile years of items and garbage in their homes. Deep down inside they know it’s wrong, but they can't be persuaded to change their behavior. Eventually, family members and friends consult them and attempt to convince them to clean up. The first clean-up begins, and it’s painfully slow; the hoarder takes days to sift through their items, inspecting each item and wondering if there’s still worth in it. In the end, the home is typically cleaner, but not in a pristine state. And it’s at this moment if something isn’t done help the hoarder with their physiological issues, they begin recollecting items.

I get what you are saying, but agree with other posters, everyone understand the "technical debt" metaphor.

Teams, with the best "software development practices" can still incur what we all understand as technical debt through no fault of their own. Ludicrous deadlines set by over eager salesmen, regulatory requirements, fickle customers etc.

I don't think it's that they are somehow addicted to behaving like that, but that all those types of things repeatedly happen in the name of "business".

Vast skill differences between developers can also have a large affect on a code base. Are they addicted to doing that? No. Do they get better over time and realise their mistakes.... sometimes ;-)

As you mention, the term 'technical debt' is just a metaphor. It is not intended to be a literal description of the problem. A good metaphor is one that helps get a point across and is useful in aiding understanding. The 'technical debt' metaphor is better than your addition metaphor, "addiction" when it comes to describing the steady state situation - when you are 'in debt'. I think it is better because in describes the 'pay me now or pay me later' choices one often faces when developing software.

I think the technical debt/financial debt metaphor has *some* validity, but very interesting and thought-provoking article, thanks!

I found myself nodding along at the addiction thing, and that feels like it's also very valid - in particular the "it'll be different next time" promise that gets made/broken on each re-write, and the instant gratification vs long term that is so often seen in bad project management. I think you're right, and maybe there would be merit in applying the same cures for conventional addiction in assisting software teams who show these traits. Food for thought, thanks for a great article!

As a recovering alcoholic and programmer let me say that you should just stick to the tried and true metaphor of technical debt. You don't have a real grasp of addiction or alcoholism as a disease. No worries, few normies really do. If you did you would see that addiction behavior is not at all a good substitute for technical debt.

@Oz: Sure, everyone understands the "technical debt" metaphor. It's totally plausible. But as it turns out, this does not help. I hardly see projects turn around due to understanding this metaphor. It's like showing addicts long term detrimental effects. They nod - and continue with the addictive behavior.

And of course you're right that vast skill differences add to the deterioration of code bases. But that's also only possible because the addictive behavior is against taking the time to get people onto the same level. Constant explicit learning is not the norm in companies - because it does not pay off in days or weeks. There is the addiction again.

@Glenn: I understand why you're clinging to the metaphor. It's established, it has a well known inventor. But try to let go of it for a moment and try to see whether the metaphor has helped to fight (!) the problem.

Has it?

Sorry, I don't see such effect. There is no change in teams' behavior because someone understands the metaphor. "Oh, I get it! We're constantly increasing some technical debt - without even knowing. Now I'll deal with that more carefully."

Let me repeat: Yes, a debt is incurred. Like when someone addicted to gambling borrows money. But it's no use to talk to such a person about debt. Nothing will change - except maybe for a brief moment. They will nod, promise to change from now on - but the next day it's all the same.

Nevertheless: Too little seems to be at stake so far to make software development more systematic and less focused on quick wins. Yes, there is little "technical debt" in most other professional services.

Of course economic decisions are made all the time. But the handling of any incurred debt does not seem as bad anywhere else as in software development. That's the whole reason why I don't think "debt" as a metaphor has much value.

If I hit my neighbor's car and put a dent in it, I'm indebted to him to resolve the situation (usually by getting his car fixed). However, I can't at that point in time answer a lot of the questions that you define as being "in debt". I don't know how much the repair will cost, I don't know how long it will take, or if my neighbor would rather have a cash settlement, or if he even cares about having an extra dent in the car.

From Wikipedia (not authoritative, but it'll do): The term (debt) can also be used metaphorically to cover moral obligations and other interactions not based on economic value.

Your description of Technical debt implies the creditor is the stakeholder/manage/owner. It's perhaps better to think of the developer as the creditor. It's you who allows the stakeholders to take on the debt (knowingly or not) and as with any good lender, you should be the one to make clear the terms of the arrangement.

@Andrew: That's an interesting thought: Should we think of the developer as the creditor?

Let's see about some attributes of creditors:* Financial creditors know (!) the interest rate exactly.* Financial creditors determine the conditions of a loan: interest rate, payback schedule.* Financial creditors can refuse to give a credit at all.* Financial creditors can demand immediate payback under certain circumstances.

All in all: Financial creditors are approached by clients in a comparatively humble way - because the have the power to defuse to give credit.

How many of these attributes pertain to developers? Hm...

* When a stakeholder is asking for a loan ("do feature B instead of finishing A in a sustainable manner"), the developer does not (!) know what the interest rate will be. They costs of the loan he's giving are not clear.* Developers certainly are not in a position to demand certain conditions of the credit they might be giving to stakeholders. Especially they cannot demand a payback schedule. Because: As soon as they start demanding payback some stakeholder will come around and very, very urgently ask for another loan.* Developers are in absolutely no position to refuse a credit.* Developers are in absolutely no position to demand immediate feedback. They may ask for it - but if push comes to shove the stakeholder will refuse to pay back.

All in all: I haven't seen any developer being approached by a stakeholder in a comparatively humble way asking for maybe a loan. Right the contrary is true: Developers (or their managers) approach stakeholders (or the guys with money) in a humble way. Because they fear to be cut off from the precious flow of money.

Bottom line: As much as I like to think of developers being creditors I don't see any evidence for that.

@Mike: Yes, debt can come into existence pretty quickly and without much forethought. That's what insurances are for.

Also debt can be incurred without much consciousness or rationality. Excessive indebtedness of households in the US is around 20%! That's probably not people who deliberate in a length manner about whether or not to buy something on credit. They just do it. Because they deem it their right or their duty as consumers? (Really poor people are not much indebted. Nobody wants to lend them money in the first place.)

Nevertheless all the attributes except maybe the first are true for these kinds of debts: the amount is known, the costs, the payback schedule, the creditor etc.

Still it does not hold for "technical debt". Just let me pick two attributes again as an example:

a) What are the costs of a "technical debt"? Nobody knows when it's taken up and not the day after and not the week after. And there is no insurance to cover it.But when you put a dent in the neighbors car he'll tell you the next day after a cost estimation. Fortunately there is insurance for this kind of mishap.b) When has the debt to be payed? Well, you do that very quickly for the dent in the car. (If an insurance does not want to pay that's a different matter altogether. Let's not complicate things too much.)But for a "technical debt" nobody knows. Maybe never. (And not because that's a rational/economic decisions either.)

So even the first attribute of financial debt might not be true all the time, the others are very, very clear very fast if not beforehand.

Incorrect. That's just about the only time we do use the term. We have multiple choices on how to make a change - get 80% done by hacking it in, bypassing tests, and deliver it next week (management's choice), or take the extra weeks and do it the way we see as "right".

No, we can't give a cost now, but we *can* track the work in that same area and say "this took an extra x days because of the hack we did for that feature last month".

So perhaps your case - the one you see and have based this article on - is called "entrenched bad practices". We will continue to use technical debt as a term because that's exactly what it is, and everyone we talk to understands what we mean.

@Philip: It's great to hear there is somebody who deals with "technical debt" in a sensible way. And of course there are people who consume alcohol, nicotine, or marihuana in a sensible way. And there are people who can go to a casino just once in a while. Or get a loan only very rarely and pay it back according to schedule.

Yes, such people exist. And why shouldn't they indulge in all of this?

But... all these people don't complain about chronic pain of a kind which clearly can be attributed to long term and uncontrolled consumption of such substances/services.

This is different for software projects/companies. They complain about such effects. And that's not just anecdotal cases. It's the majority of software projects. At least the ones I know of (which is a considerable number due to my job as trainer/consultant).

If you like, call the cause of this "entrenched bad practices". Likewise you could call a drug addict's behavior "entrenched negligence of basic bodily needs".

But calling it this ("technical debt") or that ("entrenched bad practice") does not help those suffering from it. Because it's a too rational label. It sounds as if changing the behavior was easy. Which it isn't.

That's why I prefer the label "addiction". It points to the heart of the problem: loss of control.

And now for the cost side of "technical debt": You say, you don't need to know the costs, it's enough to track it later on? That's interesting and to me has no match in the financial world.

Imagine someone looking for a loan. You think she would be happy about a creditor telling her "I can give you the money - but I won't tell you the interest rate, nor will I tell you, when you should pay me back."? You seriously think this would be sane behavior regarding debt? Strange...

Whether that is a helpful point of view for the many, many other projects where people don't seem to be able to behave so rationally and sensible, to me seems an altogether different matter. And it's those projects I'm offering an alternative point of view.

Many of the accepted ways of dealing with addiction (or psychological problems in general) require recognition of what the problems are. Making comments such as "there is no such thing as technical debt" is counterproductive, you actively need to be highlighting where the problems are in your code and taking proactive steps to do something about it.

“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 paid back.”Your argument seems to be more centred around teams not dealing with technical debt rather than it not existing in the first place. If that is the case, then rather than trying to create similes between addiction/financial debt and technical debt, why not write about best ways in which the debt should be addressed.For example in the teams I run, we have a certain amount of points in our sprints reserved for dealing just with technical debt. Whilst the product owners pick the features, it’s the developers in the team who pick which technical debt will be tackled; furthermore they can mark future features as being blocked by technical debt. The developers are trusted to be making the right technical decisions, and we have open and frank discussions over why we have to do B before C. The business analysts and product owners have the understanding that if they want features sooner this is the cost and upper management understand and trust the estimates coming out of the team.

“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.”Here I would have to disagree with you, you can very consciously enter technical debt by making a technical choice to implement A over B. Whilst you may have a point that no-body knows the exact amount this can be countered by, you also have the same problem where no-body can really tell you how long the development will take in the first place, everything is based on estimates, which you get better at making as you become more experienced.It is worth noting that sometimes technical debt won’t ever be done, but this will be because the product has gone in another direction and that code would now be redundant, that’s part of being agile, you can react to changes and only develop what is beneficial to the product.

So yes Technical Debt does exist, yes it’s a suitable name, yes we should recognise it, luckily for us there are already some excellent, well known ways of dealing with it, we just need to be encouraging and educating teams and management to dealing with it better.

Accepted ways: Yes, recognition of the current situation, the true problem is needed. But that does mean to become very open, so open you even go beyond your current belief system. That's why I find it strange you think offering a new belief system like I do would be counterproductive. Why should anyone be limited to what people already believe? If "more of the same" hasn't helped yet, well, I think it's time to think and try something new.

How to best address "technical debt": Why should I write about addressing "technical debt" if I don't believe it exists? To me the root problem is the wrong metaphor. That's why I wrote this article, to offer another one. Only after that it makes sense to talk about how to overcome this kind of addiction.

Debt: How come a hepatic cirrhosis is not called "health debt"? How come lung cancer or a smoker's leg is not called "health debt"? Wouldn't it be more appropriate to talk about debt in matters of personal health? Because addiction to nicotine or work or alcohol in the end "are taking their toll", don't they?

Strangely nobody thinks of this kind of metaphor, though.

Now I'm suggesting the reverse. I see persistent (or chronic) problems in software development of many, many teams. Instead of trying to explain them with a financial metaphor I look at them from a health care point of view. The reasons for switching the perspective I have explained in plenty detail, I guess.

But even that's not precise enough, I find. Instead of "debt" I could call the software project problems "pain" or "disease". That would not be wrong from my point of view - but it would not go deep enough.

You can treat an addict for his symptoms. Try to get the liver or the lung better. Do some surgery maybe. It will provide temporary relief - but in the end... the root cause is not treated.

For the root cause some form of psychotherapy needs to be applied. But the psychotherapist does not talk about "local malfunction". She does not care much about a hepatic cirrhosis or a smoker's leg. She does not care about "pain" or "disease". She cares about mental processes, habits, belief systems etc. That's why she calls her patient "addicted" not just "sick". It's more precise, it's more to the point, the root cause.

I congratulate you to the way you run teams. All seems to be fine. No addiction visible. Talk about debt.

But just because something works for you, please don't rule out it might not work for others as well. If you're not an addict it's easy to judge addicts and call them weak, lazy, unwilling etc. What is so easy for you - to not drink, smoke, gamble compulsively and in a harmful way for your health - might not be easy for them. And it does not help them to point at some physical signs of their addiction and reprimand them for incurring a "health debt".What helps is calling the problem by its proper name: addiction. And then help the addict to find a way to admit that, reflect upon it, and start developing habits to leave the addiction.

Just because there is a nice metaphor like "technical debt" is no guarantee it's a helpful one for any or all projects suffering from chronic problems.

Especially if problems addressed by the metaphor persist - as they do for most projects (in my opinion) - it seems appropriate to start (again) searching for other possible explanations/metaphors.

I find this article interesting. Every human, including software developers and decision makers should be open minded for new ideas.

Both terms 'addiction' and 'technical debt' are metaphers and both focus on specific aspects while ignoring others or failing to explain others.

And the term 'addiction' is closer to a diagnosis than 'technical debt' (so less a metapher). But the symptoms are better described by the term technical debt.

However I disagree with Ralf's article in the following point (just my personal experience): Sometimes my boss requests me to do the fast and dirty way while I present him time estimations and long term consequences for the fast and dirty and the 'clean' solution.

For example once I made the following proposal: I can probably wrote a simple and very limited version of ASN1 parser and LDAP protocol in 10 days (due to requirements there was no open source implementation we can use) which matches the current projects needs. However if these needs change, for example LDAPS should be possible implementing this will take several months, probably more than six.

Less surprising my boss wants the fast solution. A few months later he asks for LDAPS. After taking a closer look at the RFCs I estimated that it would take me more than one year to extend the current implementation to support LDAPS.

So in this case I would answer some of the questions from the first list in the article with 'Yes' instead of 'No'.

I concur with most of the previous commenters that the term "technical debt" still is the better metaphor. If I choose to postpone "doing A right" for "doing B now", I incur technical debt. The amount is known (more or less), and the fact that I will have to pay interest is known as well. There is another form of getting into technical debt - by being careless or ignorant one can incur technical debt, too - but that is also true for financial debt. The analogy holds.

However, what you describe is not the concept of technical debt, but the manner in which development teams treat those debts. A bit of technical debt does not have to be such a bad thing, as long as you pay it back soon. The addictive or pathological behavior is the bad thing where you amass more and more technical debt without paying it back.

As with addictions it is futile to just get rid of the debt in a huge effort if one does not treat the root problem, i.e. the team behavior. And that is even harder than getting rid of the depts, because it requires each team member to be vigilant, it requires a lot of discipline not to fall back to the old ways and it will at least in the first time considerably hurt productivity.

So, technical debt does exist, but the addictive behavior does so, too, and that behavior is what makes techincal debt a huge problem.

@Sebastian: Your "simple and very limited" parser is no "technical debt". In fact I'd call your boss a very prudent man ;-) At least if he clearly has no knowledge of a future requirement for an LDAPS parser. He's no falling into the YAGNI trap. Good.

On the other hand I could say, when you were suggesting the more comprehensive parser you were trying to build a buffer. You thought it possible their might be a requirement asking for more parser power in the future... and so you tried to enarmor yourself with a thicker layer of parser capabilities.

You showed addictive behavior, your boss was sober.

We need to look closely. A "quick win" is not always what we think it is.

But again: This depends on how clear requirements are. A "good enough for now" solution is not always a "project health risk".

'Addiction' is a terrible metaphor for entropy in software development. Try talking to your manager and comparing your project to a junkie - you'll either get laughed out of the office, or a verbal warning.

@Arne: I prefer to start from a state without a name, e.g. a liver malfunction or a codebase you don't understand anymore.

We agree these things happen. And the cause we are concerned with is harmful behavior. So the effect essentially could be avoided.

Now the question is: Should the state be called "debt" or "pain" or "disease"?

If you call it "debt", then this leads to certain attributes of a cause and how to deal with the state. I tried to give a list of such attributes.

As it turns out, these attributes are not present in many (or even most) cases.

Is the name "debt" then a good name? I doubt it.

Now I tried again. I did not give the state an alternative name, but found different attributes for its prevalent cause. Then I gave this cause a name: "addiction".

From this root I can now go down a different path an give the state a name which matches the cause.

You see: "Debt" (to me) points in the wrong direction regarding a cause. That's why I say, there is not "debt". It's like saying "lung cancer" was debt. Yes, you can view it as a debt - but that usually does not get you a proper treatment.

We also could talk about "karma". Because the detrimental state of codebases is a consequence of actions. But then... would "karma" point into the direction of a solution to the problem? Sure - but I find that a tat too intangible for most conversations with software developers.

But "addiction"... that's tangible, that's something we can treat in this world, that's something many people have personal experience with.

Anyway: "addiction" is a name for a cause, "debt" is a name for an effect. I prefer to have a name for a cause, because then it's easier to find a treatment.

Sorry, but all the explanations about the mess of large code bases is missing the point. The feature sets and the vagueness of modern languages, I call your name C# and Java, combined with bad trainings are the main problems.

You can endlessly refactoring a giant code base and you don't do it the right way in OOP, because there is no right way. The OOP paradigm has no formal background and the meaning of an object is constantly evolving.

Sometimes, I linger to the old days, where the environment forces you to make small modular solutions with a simple input, comput, output behavior.

And to call the 90% of the productive people in the software industry "Junkies" misses the point. Sorry!

When my boss requested for the quick solution in my opinion it was very likely that requests for some advanced features such as LDAPS would come up - requested by him.

Hence I advised to relax the requirement 'we do not want to deal with any more open source licenses' and allow me to use a library for LDAP (which also supports LDAPS).

Furthermore I finished my minimal ASN1 / LDAP implementation in the promised time (which is no trivia). My estimation of the time required to support LDAPS was based on a first impression of the corresponding RFCs. The later estimation was based on a more detailed analysis.

At which point do so see any addictive behavior from my side?Finally, is it really YAGNI to implement something by yourself (in a very limited way) which you can get for free by using a library?

Besides that I think that the term 'technical debt' should be limited to situations where one can cleary see alternatives and pros / cons / risks of these alternatives.

Implementing something which must be refactored after some time as requirements have been changed I would not call 'technical debt' - as long as there was no real chance to estimate that the requirements would change this way. However not refactoring software after having recognized this as being necessary and slowing down product development this way I would call 'technical debt'. The reason of this 'technical debt' might be 'addiction'.

@André: I very much agree with you that a "murky" paradigm like OOA/D/P (or at least how the original idea has been interpreted and skewed) in conjunction with bad training and often low/outdated technical competency is a huge source of dirty codebases.

But then... How do you call someone being constantly knee deep in debt? "Heavily indebted" or - at least after a while - plain dumb?

Trying to make things better by finding palatable names does not work, I fear. A junkie is a junkie. Or if you like "addict" better, then that's fine with me.

Please note: For me there is no moral judgement bundled with either term. It's just a descriptive name for a common human behavior. Junkies are not bad people because they are addicted. They are first of all people who need help. Special help for a special problem leading to chronic symptoms thwarting sustainability.

@Sebastian: The whole thing hinges on what "very likely" means. If very likely means, you thought of it, but the customer did not and was unable to imagine a near term future with a need for a capability, well, then it was no requirement and not implementing LDAPS was the right thing to do.

However... using a 3rd party lib which provided the not (yet) needed features at no extra cost vs. implementing the simpler version yourself... that to me is an altogether different point. I hear "not invented here" and wonder why you even listened to you boss. Wouldn't it have been your technical expertise to decide whether to use a 3rd party lib or not? Why raise the question of "to develop or not to develop" your own lib at all?

The way I deal with technical debt is that it only occurs when we try to achieve the required functionality in a short-cut fashion, skipping the longer-term actions. This is precisely what happens with any debt. For example, I could build a house myself, working for years and adding to the house as my finances allow. I knew a guy who did this, and it took 10 years for him to finish his house. When I get a mortgage, the bank gives me the money allowing me to either pay for a company to build a house quickly, or to buy an existing house...both of which I do not have money to do myself. So, the incurred debt allows me to get the job done more quickly. If there was no interest owed, borrowing in this fashion would be great, allowing people to do a lot more in a much shorter time frame. Because of the interest, however, a house ends up costing me twice as much as it would have if I built it myself, especially if I provided my labour for free. Even if I didn't, the house would still be nearly half the price as it would be if bought with a mortgage.

So, the real cost of debt lies in the payment of interest. Interest is the cost of doing something more quickly by leveraging the value of the debt. Just leaving off features of a product is not technical debt. I see technical debt as doing something in such a way that the functionality IS obtained, but in such a manner that is quicker than it would have been otherwise. The quality is NOT necessarily compromised, just like it would not be if you bought the same house with a mortgage. While the quality MAY be compromised, that is not an absolute feature of technical debt. What IS an absolute feature is the incurring of interest, which is ADDITIONAL cost as a direct result of the debt. If the actions taken to speed up a product's development cause the software to become more expensive to operate, modify, or maintain, then technical debt has been incurred. This increase in cost is the interest paid.

So, from this, it becomes clear that not all short-cuts lead to technical debt. Only those that increase the overall cost over a product's lifetime can be said to incur a debt. This debt gets paid as the company ends up paying more for a project as a result of their decisions.