Every company I have worked with has some sort of technical debt. One organization years ago was so bad, we had to do something similar to debt consolidation. We had gone years without really dealing with various problems in the code and build system. The product I was working on was delicate enough that normal feature development was dangerous. In the end, we made a special team to handle some much needed refactors in our SDK and in our now 4 hour long build.
Like all debt consolidation, this was disruptive and meant we had to do without some team members, and a lot of time was lost to coordinating and merging branches. I’m not convinced the end result was much better than the big ball of mud we started with.
I prefer a more sustainable approach to managing technical debt.
One of the most common problems I see is a build that is too slow. This is an interesting piece of debt, it usually means that a team cares enough about code quality to spend time developing lots of tests that run in continuous integration. Over time, these tests grow like a bramble. Some end up crossing outside application code and into 3rd party tools. Some end up being bad design just because they were written as an experiment and then forgot about. After a year, we have a 1 hour build. After a few years, we have a 3 hour build. Every time we try to get time to address this problem, there is a pressing go-live and features that need to be developed, or an important demo that can’t be interrupted. There is always something.
I have spent weeks of my life in various organizations trying to describe how important it is to make a build faster. Two things finally clicked in the conversation. One, is that the concept of technical debt is less than meaningless to the product owners that generally control what changes are funneled into a development pipeline. The second thing, is that pipeline works based on known quantities. Each piece of work has some sort of deliverable and some assumptions about time built in.
To manage technical debt, I had to approach the problem like a product manager. I started talking about technical debt in terms of what it does. Each piece of debt is money lost or stolen away. Technical debt means releases happen slower, or feedback happens slower, or changes are more likely to introduce problems for a customer.
The other bit of this is making the work predictable. Randomly asking for time to work on technical debt didn’t go over well. It implied that we had a rats nest of problems, with more unidentified, and didn’t know how complicated each problem was or how long it would take to get fixed. Adding a small to medium sized task to every sprint removed the question on what were doing and how long it would take. One sprint we might get to an important refactor, one sprint we might work on upgrading a database and expanding storage, and another we might parallelize tests in our build to get a faster feedback cycle.
For me, the key to making any headway on technical debt has been to talk about it in a language that people actually care about — how it affects the bottom line, and how we can predictably address things.