Repaying Technical Debt

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, accumulating 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 puts enough pressure on developers that they resort to putting 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 that 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)

  1. Lack of error handling, logging (massive ROI)
  2. Un-optimized database (very large ROI, but requires high skill)
  3. Code not checked into SCM (simple, low-cost)
  4. Web apps (or other apps) without configuration/config-files
  5. Simplified (consolidated) architecture (KISS principal)
  6. Spaghetti code / code that needed to be refactored
  7. Unmonitored systems (servers)
  8. Out-of-date (out of synch) dev databases/servers
  9. Lack of governance on logs (purging old/obsolete log files)
  10. 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.

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Methodology, Programming, Review. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s