Where the Wild Bugs Are: A Primer on Finding and Taming Your Code Maintenance Nightmares
- Attacking the Dragons
- Implementing a Test Harness
- Making the Changes
- Test, Code, Test
- Any Dragons Remaining?
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Wild bugs. Dragons in the code base. Many companies are starting to realize just how much money they're spending on complex, Rube Goldberg[nd]style solutions in corporate IT. This isn't a minor issue. Any company that uses custom software[md]and that's most companies with more than a few million dollars in revenue[md]suffers when the state of its code base dictates the kinds of decisions it can make, initiatives it can undertake, or businesses it can enter.
Various articles in my InformIT series on technical debt, such as "Don't 'Enron' Your Software Project," "Root Causes of Technical Debt," and "Quality Last: Why We Make Poor Software," deal with the causes of this problem. This article focuses on learning how to find those maintenance nightmares, so that you can start paying down the technical debt that has likely been accumulating in your organization for many years.
Attacking the Dragons
Assuming that you don't have a high-level technical wizard who can use programming magic to slay the dragons in your code base, the key to attacking these dragons is to know where they live. My article "Using Metrics to Find Out if Your Code Base Will Stand the Test of Time" covers some metrics that help you to define where the dragons live:
- Cyclomatic complexity. Methods, and the classes that contain them, are hard to understand because they have a high number of independent execution paths.
- Efferent and afferent coupling. Classes that depend on a lot of other classes, or on which a lot of other classes depend.
- Instability. A ratio using efferent coupling and afferent coupling, which expresses the degree to which a class will ripple defects throughout a system.
Understanding these metrics is a key to knowing how to prioritize debt payoff efforts. In that article, I suggest paying special attention to classes with high instability, low test coverage, and high cyclomatic complexity, as those are places where defects tend to occur. Why focus on those places? Because it's common for companies to sit on a virtual mountain of bad code. Without a means of prioritizing efforts to find the most important areas to refactor, any initiative to stabilize a code base will be prohibitively expensive[md]and thus, it's highly unlikely that the organization will ever undertake those efforts. By focusing on cleaning up the areas where cleanup has the highest impact, you increase the likelihood that your organization will see the bottom-line impact of refactoring.