If we take it as a given that all of the assumptions in determining the numbers above are consistent, then, by using the above method, we can put two features side-by-side and compare the value of developing them by the return generated. In fact, this is often used as a base for feature sets, but other, real-business items like sales commitments, unforeseen maintenance issues, etc., also trod in, taking the ideal world and populating it with ugly necessities.
I've been pondering for some time on ways to quantify the costs associated with design and implementation trade-offs. Just as two features can be put side-by-side, two implementation strategies can be put side-by-side and objective decisions ought to be able to be made around those. Unfortunately, most of those decisions I've seen have come down to, at a most basic level, personal preference.
Furthermore, communicating to a non-technical audience the costs and financial risks associated with those trade-offs is nearly impossible. Because of those challenges, a breakdown occurs between development, wanting the "no risk" option, and business, who wants to properly evaluate the best ROI. The breakdown often turns into a rift as development wants "the right thing" and business wants "the cheap thing" with only weak objective communication. My technical side wants to do "the right thing", but I'm pragmatic enough to understand that sometimes trade-offs have to be made, so I try to blunder through that communication minefield, getting beat up on both sides.
Coming out of this pondering is a concept that has, apparently, been around for some time, but which is new to me. This is the notion of technical debt. Steve McConnell has a great write-up about it at his blog.
The short of it is that technical trade-offs can be measured and quantified in terms of "debt" akin to any other investment debt. Make a bunch of crappy code, you are increasing your "credit card" debt. Make a thoughtful decision to implement something using a major shortcut, you are increasing your "investment" debt.
And, just like real debt, technical debt comes with interest. The more debt you take on in your code, the more you pay to create new features and to maintain the code. Eventually, you can spend all of your money on interest payments, and provide no features.
The notion of technical debt and the effects of those debts are concepts that any business person can understand. Using a vocabulary around technical debt, better informed decisions can be made and, more importantly, a method of tracking that debt can be implemented so you can know the built-up cost of that financing.
Now that it is quantified and tracked, development and business can start making intelligent decisions about how much debt a project can handle. Fast moving, early-phase projects will likely need to rely on more debt; mature projects will probably want to limit that debt; near end-of-life projects can probably start retiring debt (a concept I wish existed in the real world!).
The important take aways become:
- Don't increase your debt through sloppiness. Debt is debt, and you have to pay for it.
- Take on debt acknowledging the future costs and only take it on when you are willing to pay that future cost.
- Track your debt so you know how much it is going to affect your project, both now and in the future.
- Make sure you make payments on that debt, both when you are reaching your borrowing limit and at regular intervals. Failure to pay on the debt regularly will compound the interest, causing you to reach the borrowing limit sooner.
As always, I'd love to hear your feedback. Have you managed technical debt before? How did you manage it? Was the concept an effective tool for you?