

Technical Debt is Johnny Cash's Caddy of Software - scotch_drinker
http://mentalpandiculation.com/2011/03/technical-debt-is-johnny-cashs-cadillac-of-software/

======
DanielRibeiro
Uncle bob put it very eloquently as well in his _A Mess is not a Technical
Debt_ [1]

[1] [http://blog.objectmentor.com/articles/2009/09/22/a-mess-
is-n...](http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-
technical-debt)

~~~
Stormbringer
Interesting... but I note from the article:

 _"In short, the business has decided that it can afford to delay release 2 in
order to accelerate release 1. Is this wise?"_

This isn't actually what happens. Yes, release 1 gets pushed out the door
asap, but then 'the business' expects release 2 to be done exactly as fast as
release 1 was. So 'the business' never consciously makes that choice. All they
hear is "do you want release 1 now or later?" and of course, they pick now
(who wouldn't?).

Even if you try to explain to them about the concept of technical debt and how
this will delay release 2, all they will hear is "blah blah blah option (a)
release 1 faster, option (b) release 1 slower".

There is an element of delayed gratification to not accumulating technical
debt, and large organizations tend to have amazingly short term view points.

\----

But personally, I don't believe incurring technical debt makes you faster in
the short term. I don't see technical debt as 'getting a loan' e.g. it gives
you more resources now but you have to pay it back later on... I see technical
debt as pouring a bucket of tar over yourself.

Technical debt, and bad designs start slowing you down immediately.

Moreover, it is almost never the programmers who decide to incur technical
debt, my experience is that it is some team of architects or managers who
decide to incur the debt (e.g. by picking Vendor X's product that is a pain in
the butt to integrate with your existing systems), and they are never the
people who have to pay the debt back.

It is the programmers who have to pay the debt back, usually by way of unpaid
overtime ... as the same managers who incurred the debt in the first place
stand over them screaming about missed deadlines.

An example of technical debt handed down by the architects might be a
particular toolset that doesn't _quite_ work together, or some bondage and
discipline around the methodology, or some arbitrary restriction to increase
the difficulty (e.g. slapping everything with patterns whether they need them
or not, or desgnating a particular database for persistence, but then telling
the develoeprs they're not allowed to use SQL (yes, it's a silly and arbitrary
example)). Another example is that architects love complex abstractions, so if
you give them half a chance they'll spend their time adding layers of
indirection to your design. This makes it much harder for the developers.

Hence my bucket of tar analogy. It's bad enough when you pour it over
yourself, but if you're already in a tar pit and the people on the sidelines
are throwing it onto you... it's infuriating.

~~~
demallien
Good points, though I disagree with this: "Moreover, it is almost never the
programmers who decide to incur technical debt"

In my experience this is sadly not true. There are an awful lot of programmers
out there that don't even understand that technical debt exists. I see it a
lot amongst inexperienced programmers.

The worst thing about technical debt type issues is that it is very difficult
to explain to someone why there is a problem. You have a young programmer,
fresh out of uni, and you ask them to build a small subsystem, which they do
with much enthusiasm. Then in the code review you see a bunch of practices
that are going to make life difficult down the track: naming conventions
haven't been followed, huge 500 line functions, tests are brittle if they
exist at all, the code is full of handlers for special cases, instead of
finding a single algorithm that elegantly handles all nominal cases, things
like that.

The trouble is, the code works, kind of, so it is hard to explain to someone
why code in that state is not acceptable. Furthermore, I can happily accept
code that doesn't meet one of those criteria that I listed above, but when you
start to have multiple infringements, code just becomes unmaintainable. It's
not a clear cut case of something that you can point to and say "that's
wrong", but more of a overall cumulative effect. I eventually had to let one
guy go because I just could not get him to understand that this stuff was
important when you're building a big system.

~~~
Stormbringer
Sorry, I meant "if there are sufficiently stroppy senior developers who can
knock some sense into the other developers, it is almost never the programmers
who decide to incur technical debt".

But, sadly, even that isn't true.

It really comes down to the complexifers vs the simplifiers. The complexifers
generate technical debt simply by existing. They can't _not_ generate
technical debt, because they love complexity and create it to the full extent
that they are capable. Thus getting rapidly out of their depth† and hence the
tar pit analogy.

NB: architects are usually, but not always complexifers.

†since there is that old saw about debugging being twice as hard as writing
the code, therefore if you write code to your limits you by definition aren't
smart enough to debug it.

------
jdp23
Great analogy. Also a good point: "One thing to keep in mind, technical debt
is a sign of success. Without the continual driver of success, systems don’t
evolve to the point of having technical debt. But it’s important to always be
aware of the debt, of its force and effect on the flexibility and
maintainability of the system."

------
brudgers
> _"One thing to keep in mind, technical debt is a sign of success."_

Absolutely. Or as the song goes: "...she opened the door and said, 'Honey,
take me for a spin'"

