

Everything Gets Painful & Slow as You Scale - grueful
http://moz.com/rand/its-not-just-technical-debt-everything-gets-painful-slow-as-you-scale/

======
adrianhoward
Interesting that this repeats Martin Fowler's definition of technical debt
(<http://martinfowler.com/bliki/TechnicalDebt.html>). While Fowler references
Ward Cunningham as the originator of the term I think he gives an
interestingly different definition.

Fowler says

"You have a piece of functionality that you need to add to your system. You
see two ways to do it, one is quick to do but is messy - you are sure that it
will make further changes harder in the future. The other results in a cleaner
design, but will take longer to put in place. Technical Debt is a wonderful
metaphor developed by Ward Cunningham to help us think about this problem. In
this metaphor, doing things the quick and dirty way sets us up with a
technical debt, which is similar to a financial debt. "

Here the decision to take on technical debt is a deliberate one. You
_knowingly_ taking the quick-n-dirty route because of time constraints, not
because you don't understand the "good" design.

Here's a video of Ward talking about technical debt (referenced in Fowler's
definition)

<http://www.youtube.com/watch?v=pqeJFYwnkjE>

Here he talks about debt being something that you notice later. You learn more
about what the solution should be, and need to go back and refactor your code
so it reflects your new best understanding of the code. Debt is something that
builds up over time, and you need to pay it off regularly so that the debt
doesn't become disabling.

At about 3:20 he talks explicitly about the idea of knowingly writing poor
code:

"A lot of bloggers at least have explained the debt metaphor and confused it I
think with the idea that you could write code poorly with the intention of
doing a good job later and thinking that was the primary source of debt. I'm
never in favour of writing code poorly, but I am in favour of writing code to
reflect your current understanding of the problem even if that understanding
is partial".

Not trying to say one definition is good, and the other bad, but the
difference gives you quite a different approach. Read Fowler's piece. Watch
Ward's video. Have a think :-)

------
wensing
After 5 years of bootstrapping, Stormpulse is finally getting some serious
lift this year and I'm experiencing the truth of this post first hand. While
not fun (growing pains are ... pains), it's encouraging to hear (from Feld's
own mouth) that this is normal.

