There is a sea of information about what technical debt is so I won’t elaborate on what it is and how to measure it. What I will elaborate on is how to pay down your technical debt in context of your business priorities.
Keeping in mind that the average business person doesn’t really understand or necessarily care about technical debt, all they really wonder is why it takes so long to get stuff done. Take, for example, the Rally story from Implementing Lean Software Development. Rally started building their agile project management software and after the first year they accumulated ‘technical debt’. Long story short, it took 14 months to get rid of it. Read the book for the details. Actually, read the book anyway, it’ll change your life. So what can you do? Read on…
Here’s a strategy you can employ to provide value to the business and pay down your technical debt at the same time.
Priorities, Priorities and More Priorities
Start off by figuring out what’s the next big thing for your business. Drive company goals with yearly initiatives broken down into quarterly initiatives and use this as a guiding light to figure out what is important to the business. When attacking technical debt you are more likely to get support from management if paying back the debt is wrapped in a business goal otherwise teams can just spin and spin on re-writes or re-architecture or other stuff that generally isn’t a good idea if it’s just done for the sake of being done.
Look at the Guts
Once you have the priority defined, use a project discovery session to look under the hood. This should happen BEFORE estimates and commitments or release planning. This is where tools can be very useful. Tools like Sonar can get you great information about the state of the codebase that will be affected by this change.
Sonar will give you code complexity numbers, test coverage, duplication and a whole bunch of useful (and some not-so-useful) information that teams can use to help the business understand the effort required to make this business goal a reality. You can also use the more subjective report that the team likes to call “man, this code sucks and is reeeeeally hard to change…and test….and…”
Decisions, Decisions, Decisions
At this point you should have a good idea of what the effort is to accomplish this business goal and now the decision has to be made:
- should you do the project at all?
- should you fix the boat?
- should you build a new one?
- should you just keep doing the same thing hoping it’ll be different this time?
The point is, you now have some REAL data in order to make a decision and it’s based understanding what the effort is to accomplish a business goal while considering the state of reality. Teams generally have a good gut feel about this already but can be talked into into ‘just getting it done‘ or be too afraid to push back. Having this data is a great backup to that gut feel.
Changing code for the sake of changing code to be better doesn’t make any sense. If you have legacy code that works but rarely changes maybe there’s no need to eliminate that debt. The best thing you can do is use business goals to drive technical initiatives because that is what will get management on board to influence a better way to work.
Now that you have some ideas for a strategy for paying off technical debt, I’d recommend Mark Levison’s article on what technical debt is and solutions for getting rid of it.