Written By: Steve Zagieboylo, Senior Architect at Calavista
Whether your software project has been under development for 2 months or 2 decades, you have some technical debt. These are grungy bits of code that you know could be better. They were expedient; your target changed; you had a less-than-stellar coder on the team; or they arose for one of a hundred other reasons. But those ugly warts are sitting in your code base and you either have to allocate some development time to fixing them or you will continue to pay the “interest” on the debt as you continuously work around them, but there’s a cost either way.
Software challenges can frequently be broken down into known patterns with well-understood and straightforward solutions.
Patterns
Software Design Patterns is a popular and very successful concept in software development. The concept was originally suggested by Christopher Alexander in 1977, who was applying to software development concepts he learned as an architect. The gist is software challenges can frequently be broken down into known patterns with well-understood and straightforward solutions. There are hundreds of white papers and books on this subject, and the approach has been proven to be very successful.
This same approach can be applied to technical debt: Most examples of technical debt can be described as one or two of a small number of patterns. By analyzing these patterns, we can hope not only to understand the cost and best approaches to fixing them, but also to understand the “interest,” the cost of living with these issues when the cost of fixing them looks prohibitive. Often the ongoing cost is more than it appears at first glance, and understanding this cost can help in prioritizing the issues. In addition, the fix is frequently easier than appears at first blush, thanks to the refactoring tools in modern development environments. But sometimes the right call is just to live with it, perhaps with a small amelioration. Either way, it is still worth the exercise of recognizing what type of debt you are looking at, and really understanding its cost.
Our List of Technical Debt Patterns
The patterns below will be covered in this series (though more might be added). Each pattern will be described in more detail; then its costs will be discussed, both the costs to fix and the interest cost of just living with the problem; finally steps will be suggested to correct or ameliorate the problem. Often, fixing a problem that you’ve lived with for months or years gives the team such a sigh of relief that they quickly recover the time spent fixing it.
- Abstraction Overlooked
- Bilingual Required
- Tree Rings
- Overburdened Class
- Copied and Pasted Code
- Too Much Overloading
- One Service to Rule Them All
Common Thread: Stop Digging!
There is one common thread across all these different problems and solutions: Once you realize that you are standing in a hole, the first step is to stop digging. You may look at the problem and think that fixing it cleanly is overwhelming, so you just continue with the paradigm you have, flawed as it is. This only adds to the problem, making any solution seem even more overwhelming later.
The approach we are advocating is to figure out what the right answer looks like, and then implement any new features using the correct approach. Allow the old and new approaches to live side-by-side for a while, and convert the old code to the new code gradually. When there is some change required in any bit of the old code, then convert that one to the new approach, as part of the change. Perhaps convert others as there is time. Always, make sure that there are good unit tests, so you can be sure that your conversions have not broken anything.
For some of the patterns, this approach works very well; for others, not so much. This will also be addressed in the upcoming blogs in this series.
