We all know that technical debt, in general, is one of those things best avoided. Well I’ve got a little dirty secret to share… On almost all projects I’ve worked on that I can think of, we’ve had some form of technical debt. Gasp! Shock! Horror!
The funny thing is that I think there is a time and place for certain amounts of technical debt. Similar to the financial concept of debt, leveraging (sometimes called gearing) allows you to use a certain set of resources in such a way to magnify the potential outcome. In terms of software, the outcomes you might want to achieve include meeting certain deadlines based on opportunity cost or prior customer commitments, or trying something risky in a market that will reward you (albeit potentially negatively). It is a lever you may choose to play with.
The difficult thing with software technical debt is that it’s difficult to understand the associated interest you pay with it. At least with classic financial debt, someone has already done the hard work of converting the calculated risk into a number.
So what can you do about it?
- Start by identifying the technical debt on your project. Put this list up somewhere – on a Big Visible Wall, or a wiki shared by the team somewhere. Keep it up to date.
- Review the items constantly. Understand their rough impact (the interest payments) and how large they are (how long it will take you to pay it back). Sometimes the difficult part is knowing how to pay it back most effectively (trade the debt for equity? trade it for a different type of debt?)
- Pay back what you can. If it’s small amounts, it’s probably better just to get them out of the way so you can focus on paying back the larger debts.
- Make careful choices about what you add to it. Don’t keep making short cuts all over the place as it all adds up in the end. If you add to the list, consider what benefits you’re trying to get and if it’s really worth it in the long run.
