
Technical debt - dandrewsen
http://en.wikipedia.org/wiki/Technical_debt
======
michaelfeathers
Technical Debt is a great metaphor, but it is just a metaphor. I've seen
people try to quantify it and it just seems ridiculous. They try to take some
measure of badness and then multiply it by the number of person hours it takes
to correct it.

Much of what counts as badness in code never gets in the way until you have to
understand or touch a particular area of code. The impact depends upon change
cases.

~~~
wpietri
Hi, Michael! I agree it is hard to quantify, but many things are.

A good analogy is deferred maintenance [1]. That's where you fail to maintain
something like a building or a piece of machinery. There's a new and
complicated federal standard for measuring it. [2]

Measuring technical debt for software is especially hard, because we don't
measure much else about it. Programmers sit around coding, presumably creating
a valuable asset. But it's hard to say what the value is, so we mostly don't.
That makes it even harder to estimate how bad code reduces the value of that
asset.

One easy proof that it's more than a fuzzy metaphor, though, is how often
people declare technical bankruptcy. There's the total rewrite, our equivalent
of Chapter 7. [3] And we have the partial rewrite and the cleanup around a
major new version, both akin to Chapter 11. [4]

I agree that some of those rewrites are driven by new use cases just being so
wildly different than the old ones that it's on longer the same system. But a
lot of what I'd call technical debt would have to be cleaned up for most
likely changes.

One could look at it from an "if we don't change it, the debt never counts"
perspective, which makes the debt look as if it isn't real. But I have yet to
see a software project that keeps running for an extended period without
anybody wanting to change it, so I think that perspective is a false
hypothetical.

[1]
[http://en.wikipedia.org/wiki/Deferred_maintenance](http://en.wikipedia.org/wiki/Deferred_maintenance)

[2]
[http://www.fasab.gov/pdffiles/handbook_sffas_42.pdf](http://www.fasab.gov/pdffiles/handbook_sffas_42.pdf)

[3]
[http://en.wikipedia.org/wiki/Chapter_7,_Title_11,_United_Sta...](http://en.wikipedia.org/wiki/Chapter_7,_Title_11,_United_States_Code)

[4]
[http://en.wikipedia.org/wiki/Chapter_11,_Title_11,_United_St...](http://en.wikipedia.org/wiki/Chapter_11,_Title_11,_United_States_Code)

------
majc2
Technical debt isn't drastic enough to get people's attention - in particular
management. I prefer to talk about the technical credit card - I find that it
gets across the point that the debt needs to be addressed.

~~~
angersock
I think a better metaphor is sub-prime loans...as long as you can hand the
codebase off to the next schmuck while turning a profit, everything's fine,
and they do the same, and so on and so forth.

One day you lose your home.

