In an experience report on the benefits of object-orientation for OOPSLA ‘92, Ward Cunningham observed:
Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.
Cunningham’s debt metaphor has since become popularized as “technical debt” or “design debt”. The analogy applies well on several levels.
Debt service. Steve McConnell points out that where there’s debt, there’s interest. Not only do you eventually have to implement a correct replacement (paying back the principle), but in the mean time, you must work around what you implemented incorrectly (that’s the interest). Doing it wrong takes up more time in the long run, although it might be faster in the short term.
Deficit coding. Some organizations treat technical debt similarly to how some governments and individuals treat fiscal debt: they ignore it and just keep borrowing and spending. In terms of technical debt, that means ignoring the mistakes of the past and continuing to patch new solutions over old problems. Eventually, though, these patches take longer and longer to implement successfully. Sometimes, “success” gets redefined in terms of the minimum required to get by. More significantly, the entire system becomes more brittle. Nobody fully comprehends all of its dependencies, and even those who come close can’t make major changes without breaking things. Users begin to wonder why problems take so long to get fixed (if they ever do) and why new problems arise with every release.
Write-offs. You always have the alternative of declaring technical bankruptcy. Throw out the project and start over. As in the financial world, though, the consequences of that decision aren’t trivial. You can lose a lot of credit with users and supporters during the interim when you don’t have a product. Furthermore, a redesign from the ground up is a lot more work than most people realize, and you have to make sure it’s done right. The worst possible scenario would be to spend millions of dollars, years of effort, and end up with only a newer, shinier pile of technical debt. The very fact that you’re considering that kind of drastic measure indicates strongly against your success: the bad habits that got you here have probably left thousands of critical system requirements completely undocumented. Good luck discovering those before you ship something to customers.
It’s not all bad. Strategic debt can leverage finances, and the same holds true in the technical world. Sometimes you need to get to market more quickly than you can do it the right way. So, you make a strategic decision to hack part of the system together, with a plan to go back later and redesign that portion. The key here is that you know that you’re incurring a debt, and it’s all part of a plan that won’t allow that debt to get out of control. It’s intentional, not accidental.
That’s the main benefit of using the technical debt metaphor: awareness. Too often, after a particularly bloody operation on a piece of unmaintainable code, a developer will approach his or her manager with “We really need to rewrite this module,” only to be brushed off with “Why? It’s working now, isn’t it?” Even if the developer possesses the debating skills necessary to point out that all subsequent changes to this code would benefit from taking some time now to refactor it, the manager would rather take chances on the future, because “we’ve got enough on our plate already.”
By framing the problem in terms of the debt metaphor, its unsustainability becomes clear. Most professionals can look at a balance sheet with growing liabilities and tell you that “somethin’s gotta change.” It isn’t always so apparent when you’re digging a similar hole technically.
No comments:
Post a Comment