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)
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 :-)
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.
2 comments
[ 3.8 ms ] story [ 27.4 ms ] threadFowler 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 :-)