
A Mess is not a Technical Debt - DanielRibeiro
http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technical-debt
======
wccrawford
Totally disagree.

A mess is definitely a technical debt. It's going to take time and money to
clean it up. You can put it off more, but it's going to make everything cost
more money and take more time than it should. Or you can clean it up now and
save that time and money.

Debt is one way that companies get ahead when they are first starting out.
Just like borrowing money, you can borrow time from the future as well.
Instead of making an immaculate product, you make something that gets the job
done and fix or rewrite it later.

And just like money debt, if you don't pay off your technical debt, it will be
a real pain. And the longer you wait, the more expensive it is.

Seriously, the analogy is crazy good.

~~~
zupatol
Ward Cunningham disagrees with your interpretation of his metaphor.

[http://www.youtube.com/watch?v=pqeJFYwnkjE&t=4m18s](http://www.youtube.com/watch?v=pqeJFYwnkjE&t=4m18s)

He explains that technical debt is code written before you have a complete
understanding of the problem to solve. You repay the debt by refactoring it
when you have a better understanding. This only works if the code is clean
enough to be refactored.

~~~
geebee
Why can't you repay the debt by just rewriting the code instead of refactoring
it?

I once paid off a technical debt incurred by a previous programmer who had
done a code and dash of epic proportions. The code was utterly horrendous, and
so many changes had been done in-place, right on the production server, with
hard coded paths, that we had to rewrite it bit by bit. We didn't even know
all the _functionality_ in it, other than that it was in active use (we found
and interviewed people to get a full sense of what it did). It took years, but
we did pay it off.

~~~
kragen
One of the "refactorings" in Fowler is "change algorithm", which I think is a
bit of a cheat.

------
jdp23
A mess very definitely is technical debt. True, as opposed to the "clean" debt
that Uncle Bob's advocating, it's a bit like getting expensive cash advances
on a credit card or going to a loan shark. A mess is likely to be a lot harder
to discharge than the technical debt that comes from careful well-crafted
decisions; the approaches you need to take may be different; and there's an
increased chance that you won't be able to get out from the burden of debt.
But it seems to me that all of those points fit in very nicely with the
general analogy of debt, and I'm not sure why Uncle Bob thinks otherwise.

------
cellularmitosis
I agree conceptually, though I happen to map different semantics onto the same
concepts.

let's coin a term, "muju". What the author describes as technical debt is good
muju, and a "mess" is bad muju.

I believe in the same good muju / bad muju concepts. The only difference is
that I use the term "technical debt" to refer to both of them. While the
author only uses technical debt as a non-pejorative term, I use it as both a
pejorative and non-pejorative term.

For me, the analogy of debt still works -- its all a matter of how responsible
you spend the money. Take a home equity loan as an example. Spending it on
renovating the bathroom and kitchen is (at least historically) likely to be a
positive ROI. That's good muju (the author would say "technical debt", I would
say "good technical debt"). Spending it on a new sports car would be bad muju
(the author would say "a mess", I would say "bad technical debt").

------
bendotc
What he's calling "a mess" certainly is debt.

In money, debt is debt, whether you acquired it by taking out a responsible
mortgage or running up your credit card on bottles of Dom Perignon to impress
your friends. In software, technical debt is technical debt whether it was
wise or not. The point is, you're paying for it when you try to do other work
on the project (interest) and it's gonna take time to fix (principle).

Saying "A mess is not technical debt" is silly. The metaphor is useful whether
it was a good idea to get into debt or not.

Edit: s/Don/Dom/ -- thanks for the pointer!

~~~
nasmorn
Totally tangentially to the post I just confirmed that it is called Dom
Perignon and in doing so I learned that they have a massive technical debt
with their website. Or maybe the requirements were in the line of, build us
the slowest flash website imaginable and can you create a loading graphic that
looks like a rendering issue?

------
mechanical_fish
I'm throwing up my hands and giving up on this metaphor. It was a nice try,
but from what I can see, the heat-to-light ratio is way out of whack. Every
discussion of "technical debt" either gets bogged down in definitional issues
("is there a difference between debt and a mess?", "Is it debt if it was
planned but not if it kind of happened by accident?") or it gets bogged down
in overextension as people try to figure out the metaphorical equivalent of
"interest" or "refinancing" or "bankruptcy". As if any of these concepts
necessarily applied.

I think I'll just go back to the plain words. There is good code, bad code,
and ugly code. There is flexible code, and brittle code. There are planned
short-term jury-rigs, unplanned baked-in design mistakes, and fragile
temporary solutions that never get fixed because the company pivots before it
matters.

~~~
salvadors
I think the metaphor is mostly lost on people who have never taken a business
loan. Generally banks don't like lending money to companies purely to cover
normal operational expenses. If you simply have cash-flow issues then a line
of credit/overdraft is better. If you can't meet your costs out of income,
then you want to either reduce costs or find an additional equity injection,
not take a loan. Traditionally loans are for things that will grow the
business, with a clear path to being able to repay it out of the additional
income generated as a result. Obvious examples are buying expensive new
equipment to let you produce something you sell at a greatly reduced cost, or
opening new retail outlets.

The business world has a fairly well developed set of nuances around whether
the debt a company has is good debt or bad debt. AIUI Ward's original point
was simply that the "all debt is bad" approach doesn't work in business, and
shouldn't be applied in so blunt a manner to technology either. Sometimes it's
worth going into some debt now to achieve a future benefit. But, a business
should be just as careful with its technical debt as its financial debt: only
going taking it on with a clear (and well measured) path out again.

But, as you say, like pretty much any metaphor, stretch it too far, and it
falls apart.

------
jrockway
I like this distinction. I think a lot of people hear about technical debt and
then feel OK about writing shitty code. But in reality, taking on technical
debt is a calculated engineering risk, not sloppy work that "a mess" is.

With that in mind, I've never seen a codebase with any technical debt.

------
angdis
I think some people are getting retentive about applying the "debt" metaphor.

Uncle Bob is simply trying to draw a operational distinction between technical
debt that is accrued deliberately and technical debt that is accrued out of
sloppiness.

That later is a transgression that is definitely a mistake and should be
avoided, the former is a calculated risk that is a part of this business. It
doesn't matter what you call them as long as you recognize the difference
between these two conditions and what they mean.

~~~
rue
Perhaps Uncle Bob ought use a metaphor that applies better, in that case. I
don't think the fault is in the reader.

------
Tichy
Or you could just launch. This technical debt thing has to be the silliest
meme ever.

I mean yes, presumably since I haven't saved enough for retirement yet, I have
"retirement debt". As long as you live, you always have some kind of debt
because you could use your future time to earn more money (or create cleaner
code or whatever). So I suppose you owe yourself your future self.

It is debt in the widest sense - but not a useful concept. Obviously you have
to do in the future what you can't do today.

Technical debt is merely a chimera created by consultants who want to justify
their high costs.

Another illustration: if I build a tent to spend the night, have I accrued
technical debt because I owe myself a proper house? _shakes head_

~~~
icebraining
I'm far from an expert, but from what I can tell the debt occurs because
you'll have to "pay" it to move on.

To use your tent illustration, there's no debt because you don't plan to grow
the tent into a proper house - the product is finished.

Now, if you actually wanted to build a two story house, but built a tent
instead for now because summer's already here, you'll then have to "pay the
debt" of dismounting the tent so you can rebuild the house properly.

~~~
Tichy
Sure, but I think you could almost always make the case that whatever you do,
you have incurred "technical debt". Otherwise you would make perfect decisions
all the time, which is impossible.

Another danger with the technical debt thing is that it could lead to
expensive premature optimization. For example while you are camping out in
your tent, maybe you get a job offer in another city. Or a motorway is about
to be built across your lawn. Had you needlessly started with heavy
foundations of your house, that effort had been wasted.

Who benefits from the TD theory is the builders of the house foundations. Or
the consultants who want you to use Java Enterprise Beans instead of Sinatra.

------
pdx
You may choose not to call it technical debt, but you have to call it
something, and it seems very much a debt to me. The term you use to describe
it doesn't get to cast judgement as to the merits of the debt. The debt may be
inherited debt from an acquisition, for example. Any judgement you would
choose to cast regarding the debt's merits does not necessarily reflect on the
current holder of that debt, but the debt is just as real. If I buy your
company and you have debt on your books from stupid decisions that did nothing
to advance your company, it's still debt that I now owe.

If it causes inefficiencies that could have been avoided, it's technical debt,
regardless of the cause.

------
gfodor
Here's another way to look at it. Technical debt is real when you see it first
when looking forward, before it's realized. Technical debt is bogus when you
see it first when looking backwards, after it's 'realized.' Like real debt, it
doesn't just 'appear' without a conscious decision to incur it.

For example, a system was built crappily, and you refer to it later on as
incurred technical debt. _bzzt_ wrong, if you didn't call it technical debt
when the system was being built, it probably was just a mess and now you're
calling it technical debt to hide the crappiness.

~~~
Deestan
> For example, a system was built crappily, and you refer to it later on as
> incurred technical debt.

But, a crappy mess will _become_ a technical debt the moment you recognize it
and make a business decision not to spend time on fixing it right now.

------
spuz
The way I define technical debt is something that risks wasting someone's
time. If you decide to make a change quickly to get something working and
create a mess in the process, then it's possible that that mess will waste
someone's time when it comes to making other changes. Note this is separate
from a mess that can cause bugs. For example a significant lack of unit tests
I would classify as a business or data risk - anything that risks losing
customers should be given higher priority than technical debt.

------
nowarninglabel
"When you buy a house and take on a big mortgage debt, you tighten up all your
spending and accounting."

No, actually it's the exact opposite, both in the short term, and in the long
term.

Short-term vs. existing homeowners:
[http://www.nahb.org/generic.aspx?sectionID=734&genericCo...](http://www.nahb.org/generic.aspx?sectionID=734&genericContentID=106491&channelID=311)

Long-term vs. non home-owners: [http://www.philadelphiafed.org/research-and-
data/publication...](http://www.philadelphiafed.org/research-and-
data/publications/business-review/2010/q3/brq310_benefits-and-costs-of-
homeownership.pdf)

More: [http://econ.jhu.edu/people/ccarroll/papers/COS-
WealthEffects...](http://econ.jhu.edu/people/ccarroll/papers/COS-
WealthEffects-Literature/Papers/Engelhardt.pdf)

There is a lot more info out there about this, but the economics of it are
pretty simple. The fact that the author can't even get this right makes me
question any other assertations made in the article.

------
nordsieck
The author is unfortunately conflating two (albeit related) arguments.

1\. There is a difference between a bad decision and a trade-off that you will
(probably) have to re-visit in the future.

2\. Writing messy code is a bad decision.

Irregardless of whether you think point two has merit, point one is the the
soul of the article.

