I particularly enjoyed this excerpt from the online example chapter of Joshua Kerievsky’s book, Refactoring to Patterns:
Design Debt
If you ask your manager to let you spend time continuously refactoring your code to “improve its design,” what do you think the response will be? Probably “No” or an extended outburst of laughter or a harsh look. Keeping up with an endless stream of feature requests and defect reports is hard enough! Who has time for design improvements? What planet are you living on?
The technical language of refactoring doesn’t communicate effectively with the vast majority of management. Instead, Ward Cunningham’s financial metaphor of design debt [F, 66] works infinitely better. Design debt occurs when you don’t consistently do three things.
1. Remove duplication.
2. Simplify your code.
3. Clarify you code’s intent.
Few systems remain completely free of design debt. Wired as we are, humans just don’t write perfect code the first time around. We naturally accumulate design debt. So the question becomes, “When do you pay it down?”
Due to ignorance or a commitment to “not fix what ain’t broken,” many programmers and teams spend little time paying down design debt. As a result, they create a Big Ball of Mud [Foote and Yoder]. In financial terms, if you don’t pay off a debt, you incur late fees. If you don’t pay your late fees, you incur higher late fees. The more you don’t pay, the worse your fees and payments become. Compound interest kicks in, and as time goes on, getting out of debt becomes an impossible dream. So it is with design debt.
Discussing technical problems using the financial metaphor of design debt is a proven way to get through to management. I routinely take out a credit card and show it to managers when I’m speaking about design debt. I ask them, “How many months in a row do you not pay down your debt?” While some don’t always pay off their debt in full each month, nearly all don’t let debt accumulate for long. Discussions like this help managers acknowledge the wisdom of continuously paying down design debt.
Once management accepts the importance of continuous refactoring, the organization’s entire way of building software can change. Suddenly, everyone from executives to managers to programmers agrees that going too fast hurts everyone. Programmers now have management’s blessing to refactor. Over time, the small, hygienic acts of refactoring accumulate to make systems easier and easier to extend and maintain. When that happens, everyone benefits, including the makers, managers, and users of the software.
Previous Topic
