Software development is all about making tradeoffs. Sometimes, we do stuff because it’s quicker and get things out of the door faster, not because it’s the best option long-term. Do software development long enough, and you’ll learn the term “technical debt” – which is formally defined on Wikipedia as “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. A more informal, but probably just as accurate definition could also be “the price(s) you’re paying now to have shipped things earlier.” Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off when there’s no other alternative.
I just spent weeks trying to update 1 of our apps to retrofit it for better mobile support. This app was built in 2014, when mobile browsing wasn’t considered a priority. We wound up tacking on some mobile support later, but it was a rush thing and we made some trade-offs in the name of tacking on mobile support on top of what we had already. Fast forward about a year after that, and we need to introduce some more mobile changes. We made some design decisions with the intent of getting this update out the door faster, but obviously weren’t in the long-term interest of doing this properly. We got the update shipped, but there’s a lot of technical debt, both from the “just ship it” decisions I made to get the work done, and just the way circumstances and use cases have changed since the app was first written. The app is going to need a major refactoring, if not a complete overhaul, and it’d be nice if I had a record-keeping system that listed the nature of the tradeoff and gave an example of what we did, and the price that incurs. We could also note the way the user requirements have changed over the course of the years that call into question our older design decisions. I think if we could see this stuff pile up, we’d feel a lot more urgent call to go back and re-engineer our software for modern problems.
Part of why I’d like to have a ledger for things like technical debt is that it’s often hard to convince managers of the need to go back and pay down technical debt early. Having a tool that visualizes your technical debt at least encourages the people responsible for prioritizing work to see the impact this debt is having on your codebase. By having them see the limitations on the software that can be corrected before they become big problems. It’s not as sexy or flashy as implementing new features, or all-new apps, which is why it’s important to make sure the work is somewhere it’s visible, as well as what doing it means for your organization.
Given the fact the real penalty for technical debt is paid when you’re trying to do important work later, it’d be nice to have something showing just what you’re giving up unless you go back and refactor your code. Ideally, you’d pay this down before things get too bad, otherwise you’d find yourself running into the same problem Netscape did years ago, having to rewrite your entire application with no new features to show for all the effort.
So how would this ledger work? Well, for starters it has to track what we can’t do because of current technical debt. It should also be updatable to note any complications to subsequent work or things you can’t do yet because for old design decisions. At this point, you’re tracking the “principle” (the original design decision causing technical debt) and interest (the future work that was impacted by the debt). The more things enter into that list, the faster you can talk product owners into prioritizing clean/up this work.
Ideally, it would fit into any existing ticketing system you already use. After all, you’re already tracking those, and tickets are in theory (being reviewed) by product managers. Filing a ticket as soon as you make a short-term tradeoff that you know you need to go back and fix at least keeps the issue front and center when planning your workload. It also underscores the need underlying issues in your application that need to be dealt with to the people responsible for prioritizing what gets worked on next.
Paying down technical debt is important, but before you can do that, you have to actually know what technical debt you’ve incurred. And that means keeping track of it. Preferably you can do this through your normal ticketing system, but even if that’s not viable, you should still be tracking it somewhere. Tracking technical debt keeps it visible which is the first step to making sure it gets paid down. Otherwise, you’re just setting yourselves up for a lot of time lost on a massive re-write down the road.