- Don't "Enron" Your Software Project
- Technical Debt: A Primer
- The Enron Model of Technical Finance
- Technical Fraud
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Technical Debt: A Primer
Why do we spend 80% of our software development budgets on software maintenance? Simply put: Despite our better instincts, it's still too easy to do the wrong thing when developing software. One example is the practice of "cut-and-paste coding." Suppose you have a sales compensation system that computes commissions. A batch process runs during each payroll to perform the commission calculation. This process sits in the payroll system, but somewhere else, perhaps in some commission dashboard that your salespeople use to see interim progress, you have the same commission calculation. As the business sponsor of the system, you signed off on this system after it was built initially. And why not? Technically, the system met its requirements—the commission calculation was correct (in both places).
The problem occurs when your commission structure changes. When someone comes along to change the system to accommodate the new commission structure, the code in at least two (and possibly more) unrelated areas needs to be changed. Worse, you have no reliable way of knowing whether all of those changes are right, without a full regression test of the system—if such a test is even possible!
In such a case, you have technical debt, defined as "the sum of future maintenance that could have been avoided if the software had been developed according to reasonable software-design practices." Cut-and-paste coding is just one way that technical debt is introduced. Designs that lack testability, inappropriate coupling, and dozens of other such practices contribute to this problem.
Why We Get Technical Debt
Like credit card debt, technical debt might "feel" good when we're in the process of accumulating it. We do things that optimize for the short term, but have a long-term expense that's far higher than the short-term gain we get—most of the time, as least. During the initial build of a system, it's easier to cut-and-paste logic from one module to another, rather than finding a way to reuse the logic. Technical debt usually comes from short-term optimizations of time without regard to the long-term effects of the change.
Interest Rate on Technical Debt
If the short-term optimizations that occur most of the time had a minor effect on maintenance (something like a 6% mortgage, say), such decisions to take on technical debt would be just fine. However, we frequently allow software development organizations to take out technical loans that, if they were transparent, would throw the corporate treasury department into a spiral of panic.
Let's look at our case study of the cut-and-paste code. The investment to do it right the first time is low (two days of work). In this case, you might write a shared module that does a commission calculation, making it available to any other module that needs such a calculation. Say we allow the development team to take out the "loan," and do cut-and-paste rather than spend the two days. In exchange for the two days of work, we'll incur future maintenance costs that are far higher. Making a conservative assumption, we'll say that we only did the cut-and-paste operation twice, resulting in the same calculation being in three places. Every time we change the commission structure in the future, we'll need to do the following:
- Find each instance where the commission calculation is performed—hoping that we got all of them (1 day)
- Make the change at each location—possibly customizing each change due to stylistic differences introduced by different developers (1 day each, 3 days total)
- Test each change, including performing regression tests to make sure that the change doesn't cause problems in seemingly unrelated places (1 day each, 3 days total)
- Put each change through the standard change-management process in multiple systems (0.5 days each, 1.5 days total)
- Discover that we missed one or two places, and repeat the process for each one we didn't find originally, upsetting the salespeople whose commissions were paid incorrectly (2.5 days minimum, plus an immeasurable amount of lost confidence)
At this point, we have 11 days of additional work invested every time we change the commission structure. Guessing conservatively, perhaps we only change the commission structure three times over 10 years (some places change it annually), we have net-interest payments of 33 days of effort, for which we were paid two days of effort up front.
The approach in this example results in a debt with an interest rate of about 32.4% (starting with two days of effort gained and paying it off with 33 days of effort lost over a 10-year period). I'm not a corporate policy expert, but my guess is that most accounting departments would balk at IT regularly taking out loans with interest rates like 32.4% that make loan sharks envious.