Edit: Don’t let things rot. Entropy is real.
Originally posted May 8, 2018 on AIXchange
This Twitter discussion got me thinking about technical debt, a concept I discussed here:
As often as I see it, it still surprises me when I encounter a company that depends on some application, but chooses to run it on unsupported hardware without maintenance agreements and/or vendor support. If anything goes sideways, who knows how they will stay in business.
I find it a bit funny to see other tech pros take such a narrow view of technical debt. Does it only apply to software, or is it reasonable to also apply it to other areas of technology? Why not both? Why not go even further? Consider, for instance, this analogy:
In a non-technical example, imagine owning an older car that has served well but is due for retirement in three months. In three months you plan to invest in a new car because the old one is no longer cost effective due to continuous maintenance needs, lower efficiency and so forth. But before your three month plan to buy a new car comes around, the old car suffers a minor failure and now requires a significant investment to keep it running. Putting money into the old car would be a new investment in the technical debt. Rather than spending a large amount of money to make an old car run for a few months, moving up the time table to buy the new one is obviously drastically more financially sound.
With cars, we see this easily (in most cases.) We save money, potentially a lot of it, by quickly buying a new car. If we were to invest heavily in the old one, we either lose that investment in a few months or we risk changes our solid financial planning for the purchase of a new car that was already made. Both cases are bad financially.
IT works the same way. Spending a large sum of money to maintain an old email system six months before a planned migration to a hosted email system would likely be very foolish. The investment is either lost nearly immediately when the old system is decommissioned or it undermines our good planning processes and leads us to not migrate as planned and do a sub-par job for our businesses because we allowed technical debt to drive our decision making rather than proper planning.
Technical debt is accrued when we put off patching our systems or upgrading our hardware, or when we fail to keep our maintenance contracts in place. Sometimes it’s accidental. We’re told that a system will be replaced, so we hold off on patching or upgrading an application or OS. But then the promised replacement is delayed or canceled, and the next thing you know, we’re running older code and the upgrade path is far more complicated than it would have been had we kept on top of it. Or we may let support lapse, believing that servers are going away soon. Instead, soon never happens and a critical piece of our infrastructure is no longer supported. Everything from missing a change window to change freezes to lack of cycles can contribute to these scenarios.In IT, putting off change because it’s convenient is an all-too prevalent and incredibly damaging mindset. There always comes a point where replacing old technology is the most cost-effective option. Unfortunately, far too few businesses recognize this. It’s on us to make executives, and even some of our colleagues in IT, understand the true cost of technical debt. If we let things rot, they will, in fact, rot, and letting things rot is far worse than doing nothing. We must fight to retain the ability to upgrade our systems as needed.