Something wonderful happened today. This week, my team got approval to resolve some technical debt. I mean, officially work on it. Totally on-the-up-and-up, and not just squeezed-in as a rider to another fix.
Nearly every project that I have been-on has experienced some technical debt. However, the more structured the dev process, the harder it was to get permission to resolve any of the technical debt. There just wasn’t any room in the plan.
Several years ago, I worked on a team that was less structured. I was brought-in to resolve technical debt that had gotten out-of-hand to the point that, the support team and the dev team were buried with support calls. It was bad. We spent all of our time shoveling the sand that was collapsing into the pit that we were in. The frantic environment that it produced, was exhausting.
Eventually we dug ourselves out. Afterwards, we were allowed to retain a budget for discretionary work. Meaning: we were allowed to assign ourselves (some) work. Of course, any self-assigned work, was to consist of 1) resolving technical debt, 2) building IT support utilities or 3) advancing our team by implementing new technologies/improvements/upgrades. The budget was very modest: 2-3 hours per week. We were held accountable for our work. It wasn’t any kind of freebie.
I our discretionary budget paid for itself. It was pretty clear. It felt great too. I don’t know of any other teams who have had such a budget, because their management had never seen such a pronounced side-effect of technical debt. When management can see the damage that it causes and allows a team deal with it, to an appropriate degree, it can be pretty sweet.
In stark contrast, building technical debt is pretty easy. You can simply subscribe to some short-term thinking. You can choose to ignore small problems (especially if nobody is complaining about them), or even sponsor & encourage practices that cut corners and cause panicky developers to put band-aids and chewing-gum all over your project. This is guaranteed to lead to one place: “this mess is too-far-gone. We need to replace the whole thing!” Which can be really expensive .
Looking back on it (the salvage project), the turning point for us began when we established a strategic priority list. It was prioritized by the flaws that leaked the most hours and the ones that were easiest to fix. With our new priority list, we were able to directly focus on the things that mattered the most. If you ever find yourself being eclipsed by a menacing tower of technical debt, you might want to plan your assault on it, sooner than later. It will save you a lot of pain, and/or a lot of money.
For my team, this was our winning formula.
Top 10 list of technical debt (to target)
- Lack of error handling, logging (massive ROI)
- Un-optimized database (very large ROI, but requires high skill)
- Code not checked into SCM (simple, low-cost)
- Web apps (or other apps) without configuration/config-files
- Simplified (consolidated) architecture (KISS principal)
- Spaghetti code / code that needed to be refactored
- Unmonitored systems (servers)
- Out-of-date (out of synch) dev databases/servers
- Lack of governance on logs (purging old/obsolete log files)
- Code written in a weird (obscure) technology
For every hour dedicated to each of these, we regained 2-20 hours.
Our other big boost came from some simple but effective documentation. We made a tech wiki. It housed our dev standards, configs and pretty-much any info that a new/temp developer would need. It was focused and succinct. IT staff could find important support info in seconds. Our learning curve became shallow and our support graph was looking like the end of a bell curve.
So, before you get buried by support calls, you might want to devise a technical debt reduction plan, like this one. It is pretty easy to pitch to your boss, because it will be a short-term investment with long-term ROI.