Paying Down Your Technical Debt

Technical debt is bothering me lately.  Spurred on by this article, I was doing a lot of thinking about how to pay back some of my technical debt.

A little scenario background, as I observe it in Corporate IT shops.  In the type of shop I'm thinking of, IT builds applications for the business, and doesn't always get to set the deadlines, creating a scenario in which potentially weak-willed IT managers cut corners to meet increasing business manager pressure to "get things done."  What that results in is a lot of manual maintenance; for example, data updates to production systems by IT where a user interface would put both the responsibility and the ability in the hands of the users.

And this goes on for years, until someone looks out over the IT group and proclaims that the IT group is too big for the organization, or that it’s not producing enough value for the business units.  And both may actually be true.  Because over the years, IT keeps building applications, and each of those applications has a little bit of this manual maintenance associated.  Eventually the maintenance cost - which is the interest payment on the technical debt – becomes all the IT department can do, since the business wants to remain flat in staffing.

When they get to this point, many businesses look for the big kill.  “Outsource the lot of it,” they might say.  “Let’s spin up a program to rewrite everything that's currently wrong and costing us maintenance work,” is another approach.  They spin up a big expensive effort to fix the mess they find themselves in.  It’s a form of declaring technical bankruptcy, or at best an attempt to pay off the largest pieces of technical debt first (in the guise of “bang for the buck”).

I've think that both these approaches are bad.  They are often big and risky.  The big efforts often fail, collapsing under their own weight, or they might involve a huge, expensive bandwidth increase in the form of consultants who don’t know the company history, why the bad decisions were made, and what dark puddles of sticky ichor lie in wait in the legacy codebase(s).

A while back I paid off a lot of my personal financial debt using the snowball method of debt reduction.  That method suggests you pay off your smallest debts first while paying only the interest on the other debts.  If you have a couple credit cards, a couple student loans, a couple car payments, and a mortgage, don’t start by paying off your mortgage first.  Pay that $500 credit card bill off first.  That will give you some momentum and cut out some of the debt as well. 

In the case of IT projects then, this method would suggest that you stop development to the extent you can on all but the smallest creator of maintenance noise.  Do something (give the user the power to fix the errors, automate something manual, perform automated cross-checks) that eliminates that noise.  Then look for the next smallest piece of maintenance noise that can be silenced, and roll the resources from not doing the manual maintenance into fixing the next noisy thing. 

Soon, your whole team will be working on paying down some seriously large debt.  Especially since you’ll be able to see more clearly through the noise (if you have ten noisy applications, it’s hard to work on one, but if you have three noisy applications, it’s much easier to concentrate without loss due to context-switching).

Another mechanism for paying back real financial bills is to pay off the highest interest obligations first.  That is sound advice, and in the IT world, that means work first on the highest maintenance/smallest effort work to get better bang for your buck.  That’s a fine approach as well.  Often, however, you can’t always get permission to work on this type of effort.  Or naysayers say, “Well, we should just add in a little more effort, and then we’ll quiet down things more.” And the scope creeps and creeps and then the project gets too big to get done (remember, we need to work on little things first because we only have staff to pay down very minor debts).

In general, though, just don’t go for the biggest project because it will allow you to quiet the most things down (don’t pay the mortgage first).  Do whatever it takes to get momentum.  Refuse to participate in manual processes.  Be adamant about the need for change. 

Be adamant.  Be the change.