Technical Debt: Warnings & Responsibilities

On the last Tuesday of each month, join IT expert and Pluralsight author Don Jones for his IT ops news and talk show. He’ll cover the hottest tidbits of industry news and their impact on you, and feature guests that will help you improve your skills and keep up with our fast-changing jobs. These “rants” are excerpts from Don’s previous webinar. Enjoy!

Technology debt is a phrase more and more people are using these days, and it’s one of the few, rare buzzwords that I think does a wonderful job of immediately describing a real problem that we all deal with. It goes something like this:

You implement some solution that you know isn’t perfect. This is the principal on your debt – basically, the same as the principal on your house mortgage. Because this solution isn’t perfect, you often have additional workarounds that have to be in place. Other people start taking dependencies on your imperfect solution, and its workarounds. Users get adapted to dealing with the imperfect solution, and develop their own workaround processes. All of this is the interest on your debt – just like the interest on your house. The difference is that most of us actually make payments on our homes, gradually reducing the interest and principal over time. That’s not the case with technology debt.

The time will come when you’re ready to move on from that imperfect solution – but to do so, you have to pay off all that debt. Often, all at once, or at least over a very short period of time. And just like with a big balloon payment on your mortgage, paying off all that interest and principal all at once is going to be expensive and painful. But you’ll have to unwind the dependencies, the broken processes, and everything else, if you’re eventually going to move on. And you WILL have to move on – because that interest is just going to continue to accumulate.

The problem with technology debt

And that’s the problem with implementing something that you know is going to be janky in the first place. You HAVE to understand the debt you’re going to accumulate, and understand that replacing that system with something better will ALWAYS be more expensive than just implementing the right system in the first place.

But I’m not saying that you have to somehow strive to never have technology debt. Debt is a useful tool. Without debt, very few of us could ever own a house, right? You just have to make up-front decisions. For example, when you shop around for a mortgage, you look for the best interest rate, right? Same thing with technology debt – you want to reduce that interest by discouraging or preventing people from taking dependencies, try to mitigate user impact so they don’t develop workaround processes, and so on. But you have to carefully manage these things.

My problem with companies today is they tend to pick up this attitude of, “Well, this was the best we could do,” and that’s horrible. It’s like saying, “Well, 20% interest was the best I could do on my mortgage.” You’d have never taken the mortgage, because you had two digits right there telling you it was a bad idea. Technology debt just doesn’t come with a simple up-front number, so people tend to act like there’s no interest at all. But there is. And so long as you understand three things, then debt can be a good tool when used responsibly.

How technology debt can actually be a tool

First, understand that technology debt has a cost. That cost isn’t fixed, and in fact can vary over time. There’s no way to estimate it. But, second, you can definitely control costs by understanding that you’re in a technology debt situation. You can work to prevent dependencies and workarounds that add interest to your debt. Finally, try to have a plan from the get-go to eliminate that debt. Let’s look at a quick example:

Let’s say your company needs a website. You ideally want one with lots of bells and whistles, written in a modern framework. But you’re not skilled up enough to do that, so you decide to just let your team crank out a simpler website in a different language. You know the language it’s being written in isn’t going to scale like you’ll need. You’ve made the decision to take on technology debt. What that debt might buy you is time to skill up on what you really want to do – so you have to intelligently identify that as the purpose of the debt, and start working on that skill-up.

Next, you manage the debt. Marketing wants an API built, for example, so they can extract information from the site for lead generation. You stall and hold off as much as possible, because that API is going to be additional work that’ll be throwaway, and with it in place, resistance to moving to the eventual better solution will be higher. So you fight taking on that additional interest. If you do have to take it on, you try to do so by writing an abstract layer that could potentially work, at least partially, with the future solution.

Conclusion

Technology debt only sucks when you treat it like a high interest-rate credit card and when you only make the minimum monthly payments. Used intelligently, and with full awareness of what you’re doing and that it’ll cost you something, technology debt is a useful tool. Just make sure you’re treating it with respect.

Join the next IT ops news session with Don Jones here.