There has been a lot of talk recently about the U.S. Debt Ceiling. Before you all hit snooze and click the back button as quickly as humanly possible, I am not going to get into any boring financial discussion. It’s just that while I was watching Meet the Press last weekend, I realized that there is an interesting parallel to software development and technical debt.
What is technical debt? I think Martin Fowler does a great job of explaining technical debt, but it is basically a metaphor to help illustrate how systems are affected by less-than-perfect changes. There are two common scenarios:
- Unintentional Debt – This is when a developer inadvertently introduces flaws to a system. These flaws can come from lack of skill, lack of knowledge or just not paying enough attention. Have you ever hired a bad plumber to fix a leaky faucet and after he leaves faucet falls off or the pipes burst or some other new weird problem happens? It’s sort of like that.
- Intentional Debt – In this situation, the developer knows that a change may cause issues. The imperfect solution is consciously accepted, however, because doing things the “right way” will take too long. The quintessential example of this is the Boston Big Dig where they decided to cut corners all over the place. For example, they decided to cement most of the tunnel without rebar to save time. I guess they figured ensuring the tunnels don’t collapse and crush thousands of people to death was a “nice-to-have”.
I am not sure if any of the following suggestions would help congress with the U.S. debt, but they may help you manage and reduce the technical debt within your systems.
1. Write it Down
The first thing you need to do is figure out a way of effectively tracking when debt is added, what issues result from that debt and how you plan to address that debt in the future. This is easier said than done because our natural tendency is to avoid documentation and just focus on getting past any issues that come up (then have a drink and try your best to forget about them). This is one of those situations, however, where it pays to enforce a little bit of discipline within the team. Sure, it will require some extra effort from everyone to spend 5 – 10 minutes recording information periodically, but this effort will create a transparency that would not otherwise exist. Imagine if you used your credit card carelessly month after month without ever looking at a statement or having any sense of your financial health. A couple ideas for how to track of your technical debt:
- Use Tools – Defect tracking tools (ex. Quality Center, Jira, etc.) or agile development tools (ex. VersionOne, Rally, etc.) can make it much easier to track technical debt. Most of these tools allow you to create custom issue types, associate those issues with other units of work and create workflows around issues. To go an extra step, you can use wiki software such as Confluence or MediaWiki to provide summaries and analysis of the technical debt being tracked.
- Post-Change Debriefing - During the process of driving toward a goal, most productive developers are very good at blocking out anything and everything that would distract them from achieving their goal. That is a good thing, so simply modify your standard development process to include a post-implementation debriefing stage where you then can have the team document what was changed and what technical debt was eliminated and/or added. Note that for unintentional debt you may not see issues until further down the road, so be sure to document any debt from previous changes that was discovered as well.
Even if you don’t have a fancy tool or implement a new process, just do something. It doesn’t have to be perfect. The goal is to have tangible reference points to help make decisions rather than simply relying on anecdotal evidence.
2. Draw a Line in the Sand
Now that you have started to record technical debt for a particular system, you can set the Technical Debt Ceiling. This does not mean that technical debt can be measured to the point of knowing exactly when the “limit” has been reached. In fact, the reality is that in most cases the alert that a system is getting close to a debt limit comes from the general “feel” of the system owner. This general feeling typically is a result of things like production issues, support issues, development issues and (hopefully) a comprehensive list of technical debt that you wrote down per suggestion #1. Regardless of what you use to determine the limit, once you feel the system is close to it, you will basically need to make sure that the benefits for a particular change along with any technical debt you are removing is greater than any technical debt that is being introduced (i.e. benefits + debt reduction > new debt). You should probably try to do this for every change regardless of the debt limit, but the point is that it is even more important to follow this as you get closer to the limit. Essentially, the purpose of this Technical Debt Ceiling is to help provide justification for taking the extra time needed to do things the right way so that you can prevent adding more issues to a system that is already overrun with problems.
3. Clean Out Your House
My wife and I have a pretty good system for keeping my town home relatively clean on a day-to-day basis. We try to never leave dishes in the sink, clean up the baby toys each night before we go to bed and every Saturday morning we do a quick sweep and vacuum. Over time, however, my home has started to get wear and tear with things like kitchen tiles that break, scratches on the walls, the outdoor fence starting to fall apart, etc. The problem is that wear and tear can’t be fixed along with daily maintenance because typically those small things end up taking a couple of hours to fix and/or require some special equipment. So, what do I do? Well…usually nothing. Actually, I shouldn’t say that. I do write things down so I certainly have a very nice looking Google Spreadsheet with all the details of what needs to be done. But the problem is that someone has to actually do the work. Besides the fact that we are so busy with so many other things, when there is free time, it is like, “OK, would you rather watch the latest episode of Burn Notice orrrrr clean the gutter?”. Hmmm, let me think….well, I am exhausted and have a headache, but yeah, cleaning out the gutter sounds like a blast.
It is the same thing with software as we let technical debt grow little by little over time with the wear and tear of periodic changes. If you do nothing, it will continue to build up to the point where you are near that Technical Debt Ceiling and the issues within the system are causing a lot of pain within the organization. The thing is, though, it is truly hard to try to proactively put a plan in place to eliminate existing technical debt on a regular basis. The reason for this is that until we get closer to the Technical Debt Ceiling, the impact of technical debt is not painful enough in many cases to get a high priority on an organization’s backlog. It is way too easy for the business to just ignore technical debt for the sake of short-term tactical goals.
The solution is to establish some form of a Technical Debt Recovery Program. This means dedicating resources to debt reduction efforts on a regular basis as part of your standard processes. This does not have to be one specific person whose only job is to go through the technical debt list. It is much better to have every developer participate in some way. There are different ways you can do this, but one suggestion for Scrum-based teams is to try to have at least one debt reduction story with every other sprint. This would be a relatively small amount of time, but it would allow your team to get some traction. There are times, however, when it takes a larger effort to remove a particular debt. For example, moving an application off the mainframe. In those cases, you would need to get support for a larger project. If you do a good job tracking your debt, however, gaining support shouldn’t be a problem because we all work with reasonable, logical people, right?
Conclusion
Large, steadily increasing debt is not a good thing (duh). The situation with the U.S. debt illustrates how most people don’t think about debt until it is too late. Don’t make the same mistake with your software. Treat technical debt seriously and deal with it before it becomes a serious problem. If it already is a serious problem, aggressively work to reduce and eliminate it.
