Tech Debt is Anything But
Recently I’ve been involved in a lot of discussions regarding Technical Debt. A lot of the discussions boil down to “we have a mountain of tech debt, how can we pay it off?”. To me this is fundamentally the incorrect way of looking at the problem and the terminology is partly to blame. When we think of debt it’s something that you can pay off and if you don’t go into debt again you never have to worry about it. But there isn’t a system out there that doesn’t have some Technical Debt.
The most pristinely architected, well written, accurately commented, OOP, SOLID, unit tested code now, will in the future be some form of tech debt, either because the code was written with incorrect assumptions, wasn’t maintained, or the knowledge about it was lost and people became afraid to touch it.
Technical Debt is the wrong term, we should be talking and thinking about Preventative Code Maintenance.
If you think about it the products your company is creating is somewhat similar to National Infrastructure. The ‘sexy and sizzle’ parts of both Infrastructure and Code is the creation of new: new features, new products, etc. What doesn’t generate sizzle? Routine maintenance.
Take a look at this video from John Oliver’s Last Week Tonight about Infrastructure (somewhat NSFW).
The issue is you can’t take an “all or nothing” approach to Preventative Code Maintenance. For example you can’t just do one off, large projects to fix issues “the Technical Debt style” nor can you do all small incremental updates, a “Scout Coding approach”.
Preventative Code Maintenance can help catch and correct issues before they get too big. But teams need to be empowered to tackle these issues when they are small, and manageable. Far too often an issue is just tagged as a ‘Tech Debt’ item and pushed to the backlog, where it is constantly push down and deprioritized until the issue is so large the business is unwilling or unable to take the issue on, until that is the issue starts impacting the business.
But before an issue ever starts impacting production there is a time when it can be mitigated. But at the time the issue could be deemed too small or too unimportant to take care of.
Preventative Code Maintenance “PCM” should be the #3 priority permanently on your board
Why #3? Well we do need features and enhancements, it’s important to our customers and to sales. There usually is an important bug or other non-preventative issue that needs taken care of. But always plan and prioritize taking care of preventative issues when they are small, unassuming and seemingly unimportant is far more cost effective then waiting till they are costing you business. In your scheme you should block enough weight for the Preventative Code Maintenance task as well. Use Tee-shirt sizes? PCM is always an L, Fibonacci? Put it at the higher end of your scale, (5 for the places I’ve worked). Doing 2 week sprints and just use days? Give it 2 days.
At first you may only be able to get one PCM done or maybe partially done. But as time goes on you will be able to get more and more done in that time frame. Given time and effort it will end up being truly preventative. You can obviously do more Code Maintenance then just the ones you can fit into the one item, but the goal is to always be working on some PCM.
Don’t delay maintenance until it’s costing you business or customers and reached the point where it most likely is expensive and painful to tackle. Be proactive and tackle the issues when they are small, cheap and easy to fix.
If you’re a First Responder or know one check out Resgrid which is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations.
