Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell's thoughts about how to move toward the "10" side of that 10:1 ratio. Add to Technorati Favorites
December 2007 - Posts
-
[This is an expansion of one of my comments on an earlier Technical Debt post]
When you get to a point where you are debating taking on technical debt, people normally consider two possible paths, one of which is the "good but expensive" path and the other of which is the "quick and dirty" path. When teams reach that decision point, they often estimate the good path and the quick path. Those estimates will help inform which path the team should choose at that moment. But there are three more issues that should considered.
The first additional issue to be considered is how much it will cost to backfill the good path after you've already gone down the quick path? Backfilling the good path will typically be more expensive than just following the good path in the first place because the work will include ripping out the quick code, making sure you didn't introduce any errors while doing that, then adding the good code and going through the normal test & QA processes. The "ripping out" part makes it cost more to implement the good path later than it would have cost to implement it in the first place. And of course you've already incurred the cost of the quick path, so the real cost is the sum of the quick path + the good path + the cost to rip out the quick path.
If the code is really well designed the "ripping out" cost can be minimal, but I think that's the exception.
The second additional issue that should be considered is the interest payment on the technical debt. I.e., if you choose the quick path now, how much does that slow down other work until you're able to retrofit the good path? The size of the "interest payment" depends very much on the specific case. Sometimes the "interest" is really just the cost of ripping out the quick code and of implementing the good code, which isn't really interest, per se. It's more like a late payment fee. Other times the quick and dirty approach does create ongoing interest payments by making related work in that same area take longer.
This leads us to the third issue that should be considered: Is there a path that is quicker than the good path and that won't affect the rest of the system? In other words, is there a quick path that can be isolated from the rest of the system in such a way that it doesn't create any ongoing interest payment/make other work more difficult? In my experience teams often turn the technical debt decision into a simplistic "two option" decision -- good path vs. quick and dirty path. Pushing through to a third option is important because often the best path is the one that is fairly quick, albeit not as quick as the pure quick and dirty path, and whose adverse affects are better contained than those of the pure quick and dirty path.
With those three options, the decision table for deciding which kind of technical debt to take on could look something like this (assuming a labor cost of $600/staff day):
Option 1: Good Path
Immediate cost of Good Solution: 10 staff days
Deferred cost to retrofit Good Solution: 0 staff days
Option 1 cost now: $6,000
Option 1 cost later: $0
Option 1 lifetime cost: $6,000
Option 2: Pure Quick & Dirty Path
Immediate cost of Quick & Dirty solution with possible interest payment: 2 staff days
Deferred cost to retrofit Good Solution: 12 staff days
Estimated cost of "interest payments": 0.5 staff days/month
Option 2 cost now: $1,200
Option 2 ongoing cost (interest): $600-$1,800 (assuming good solution is implemented within 6 months)
Option 2 cost later: $7,200
Option 2 lifetime cost: $9,000-$10,200
Option 3: Quick but not Dirty path
Immediate cost of Quick & Dirty solution with no interest payment: 3 staff days
Deferred cost to retrofit Good Solution: 12 staff days
Option 3 cost now: $1,800
Option 3 ongoing cost (interest): $0
Option 3 cost later: $7,200
Option 3 lifetime cost: $9,000
In this example, either Option 2 or Option 3 is an attractive short-term alternative to Option 1. That is, either $1200 or $1800 is a fraction of the cost/effort of $6000. But if you select Option 2 you saddle yourself with an obligation to revise the code later--either you reimplement the good solution, which costs more, or you keep paying interest, which costs more. When you select Option 3 you introduce the possibility of choosing never to pay off the technical debt, because there isn't any ongoing penalty, and so there isn't any urgency to pay off the debt.
Bottom line: When facing the prospect of taking on technical debt, be sure to generate more than two design options. Don't oversimplify technical debt decision making to just the two extremes.
|
|
|
|