
Messy Code is not Technical Debt - mcantor
http://docondev.blogspot.com/2009/08/messy-code-is-not-technical-debt.html
======
brazzy
Who says that the person who originally came up with a catchy expression gets
to decide what it means for all eternity?

To me, the difference that Norton makes out between "technical debt" and
"messes" is at most one of degrees and in no way fundamental.

~~~
msluyter
Indeed, I think the post exhibits the "No True Scotsman" fallacy.

~~~
silentOpen
[https://secure.wikimedia.org/wikipedia/en/wiki/No_True_Scots...](https://secure.wikimedia.org/wikipedia/en/wiki/No_True_Scotsman)

------
ZeroGravitas
I see where he's going but I'm not sure I agree.

It's more like there's two kinds of (technical) debt, one kind that you take
on with a solid plan to pay it back later and the other kind, e.g. most credit
card debt or programming messes, where you're just getting yourself into
trouble with no plan for getting back out or realisation of how much interest
you're going to accrue.

Yes you shouldn't do the latter, but it's still (technical) debt and the
phrase is a handy tool for explaining why you shouldn't do these things to
less technical folks.

------
mcantor
I actually somewhat disagree with the premise of this article, but I found it
quite thought-provoking. From my standpoint as a programmer, the concept of
"messy code as technical debt" is too valuable as a tool to get my manager on
board with rewriting & refactoring to get rid of. I would consider ceding
"messy code" as part of my definition, but only if an equally expressive
phrase were coined in its stead.

~~~
Tichy
That's exactly how I think about "technical debt": it is a marketing buzzword
invented by consultants to justify higher rates.

~~~
jerf
Behind almost every buzzword is a useful concept. "Technical debt" is not one
of the exceptions.

I have found this useful to keep in mind as I step a bit into the business
world. For instance, "solution" and "value proposition" both mean something
very important; the fact that many people sling these words around with wild
abandon doesn't excuse you from needing to know what they mean. It's the same
with "technical debt" and even things like "use case".

~~~
Tichy
I am not disagreeing in principle, but I have a hard time seeing the value
proposition of "technical debt". Doesn't it translate directly to "bad code
will cost you in the end, therefore you should hire expensive consultants who
know how to code"?

I side much more with 37signals (I think it was), who said any code you write
will eventually become legacy code. Therefore I wonder if it is really worth
fussing so much about the technical debt stuff. On the contrary I have more
than once in my dark past as a Java programmer tried to do things "the right
way", only to find that a couple of months later "the right way" was just as
outdated as everything else.

~~~
mcantor
There's a big difference between trying to do things "the right way" and
finding out your code still became obsolete, and winging it to produce crappy,
unmaintainable code that will cost you hours many times over!

------
timf
I disagree in the situation where there is a business case for slinging
something fast out there: sometimes it can, and certainly _has_ for me, move
the project forward in terms of money or some other short term goal. So be it,
one can't fight gravity in certain situations (i.e., create time that simply
doesn't exist). If your goal is to _merely_ create great code then I guess
that does not apply but I suspect few (working) people are actually in that
situation.

------
chubbard
So Technical Debt is natural and expected where messy code should be avoided.
While this all may be true messy code has the same results as true technical
debt. Get too much of it and your producitivity will take a dive. Maybe with
True Technical debt (i.e. code that can be refactored to your understanding)
you can fix and maintain. Messy code will just have to be abandoned eventually
and can't be fixed.

So we all agree messy code == toxic assets? :-)

------
DanielBMarkham
Somehow I had this really deep feeling of ambivalence come over me reading
this article.

You did something, the customer is happy, but now you have to do something
more because the first time you didn't do enough.

This author says wait! It's not because you made a mistake, hacked up your
code, or changed done. That's some other thing, but not technical debt.
Technical debt is when your understanding of the domain evolves and you have
to refactor.

So who cares? From the customer's standpoint it's more stuff you have to do.
Stuff that doesn't involve getting useful work done (in their eyes)

I believe he made his point, but I don't understand what kind of difference
it's supposed to make. What? Are we supposed to invent yet more terms for
messy code or redefinitions of acceptance criteria?

~~~
brazzy
The difference is that, he claims, "making messes is never justified". Which
is somewhat divorced from the reality of real world development that
sometimes, even if you do everything right, comes down to firefighting, making
the deadline at all costs, and doing what you're told even though you disagree
with it.

I agree in that you should not justify messes by calling them "technical debt"
that you'll pay back later when in fact there is no pressing reason not to do
it right other than your own laziness. But then, that's also true for the
design variety of technical debt.

~~~
jerf
His heading is "Messes are not Acceptable"; my question is, acceptable to
_whom_? Based on the priorities I get from my customers (/bosses), messes damn
well are acceptable, and if they don't give me the time to fix them, what am I
supposed to do about it?

Yes, I do endeavor not to make them in the first place but even after years of
experience nobody can completely avoid them.

~~~
DanielBMarkham
Not only that, but _coding is an inherently messy business_. Even if you are
Uber-Coder. That's just the nature of the job.

You can choose languages and platforms that match the problem domain to the
point of minimizing this, but it never goes away. _And the longer code sits,
the more "cruft" builds up on it_. Once again, you can minimize this, but it
never goes away.

I think once you learn good coding practices and start groking how easy that
makes things, you start getting this bad attitude towards everybody else.
_Those other stupid programmers,_ you think, _If they were only as smart as I
am most of these problems would go away_.

Later on you figure out that some of these guys are actually smarter than you,
read all the books, could do and teach this stuff in their sleep, and know
that their code needs work. At that point you're just beginning to become a
true professional.

------
edw519
_Technical Debt is accepted by many as a natural part of the development
process._

If you don't know how to avoid it, then calling it "natural" allows yourself
off the hook from getting any better.

