Do you have a technical debt problem? Just like having too much personal debt can lead to financial ruin, technical debt can ruin a project. Ward Cunningham created the metaphor of technical debt to put a concept around coding cruft that need to be addressed.
The problem I come across in most projects is that the technical debt is scattered. It may be in the heads of the developers, in TODOs through the code base, on a backlog, in JIRA, on a special board devoted to technical debt. The problem becomes that it’s scattered and disorganized. Worse, it’s often invisible or indecipherable to the business owner making the decisions.
This leads to the technical debt piling up over time and rarely being addressed. So what would my perfect solution involve?
Consolidate the debt
First off, track all technical debt in a single location. Tracking it in multiple places only leads to confusion and makes it more difficult to address the problem. In addition, it’s hard to see the relationships between technical debt when the problems are noted in multiple places. Just like an Agile project has a backlog where all work to be done is tracked, technical debt should be tracked in the same way.
Eliminate Broken Windows
Broken window theory was first related to software development in the Pragmatic Programmer. Essentially, we don’t want people thinking sloppy code is the norm, it triggers bad behavior. Just like no one would consider littering in a beautiful, pristine park, developers avoid adding undesirable code to a clean code base. Notating technical debt should look appealing and should call out code that is undesirable to show that it is an exception, rather than the rule.
Make it obvious to everyone
Technical debt should be obvious to the developers, to the agile coach, to the business owner(s), essentially all those involved in the project. Without this, it is difficult to know what needs to be done and get it prioritized appropriately. If you are strictly following a prioritized backlog, not making technical debt obvious means it may never get resolved.
Tell me why there is benefit
When looking at technical debt, everyone should understand why there is benefit to addressing it. This could mean that we give a description of why it is beneficial, or we call out the reasons why not addressing it would be harmful to the project. The key is having everyone understand the reason the problem should be dealt with.
Keep it close to the code
This makes it easier to pinpoint exactly what code is causing the issue. Without this, there may be confusion as developers move on and off of a project as to where the issue was and how it can be addressed. Simply saying, “Address performance issues in the retrieve employee query” may lead me on a chase through the code to determine which employee query we are referring to. This also helps alleviate the broken windows issue discussed previously.
Track metrics about the problem
Metrics are critical to understanding a problem. How can we determine ROI if we don’t understand how difficult the problem is? At the very least we should provide some metrics describing the complexity of the problem and the value of solving it. These numbers may change over time, but at least they give us some quantifiable information about the problem.
So this is what I would like to see out of a solution to the technical debt problem. If you have any additional ideas, please leave them in the comments section. In the next post, I will give the advantages and disadvantages of the approaches I’ve seen to addressing the problem. In addition, I’ll provide an alternative solution that addresses all of these concerns, so stay tuned.