Compounded Technical Debt can Cause Significant Business Disruption

Software is expensive. It’s expensive to create, modify and maintain. That said, virtually every business today owes its continued success to software. Modern organizations need modern software. Virtually every IBM i organization today is heavily invested in its core IBM i application. They know this application empowers the organization to deliver its unique business value and that the application is irreplaceable given even a generous dollar and time budget. A problem with the application has the potential to cause a substantial business disruption.

Why, then, do so many IBM i shops take their software for granted?

Your Software Won’t Run Forever

Ward Cunningham is credited with having defined technical debt more than 25 years ago (bit.ly/2SaVHSu). Technical debt is the cost of work you need to expend to resolve poor programming shortcuts (What programming manager hasn’t said, “We’ll make it better later; let’s just get it running for now.”) or other short-sighted software decisions. Poor or no documentation, bad coding conventions, coding before you design and a plethora of other factors also contribute to technical debt.

One of the most subtle causes of technical debt is failure to keep your software upgraded and current. Upgrades cost money, require time and effort, and may surface other technical debt ready to come due. And many managers argue that after you spend all that money and time upgrading, you’re basically (at least on the surface) left with what you had with a bigger version number.

The problem with this in-the-now thinking is that a software upgrade avoided isn’t a debt saved, it’s a debt deferred. There will come a day when you have to upgrade and the longer you avoid that day, the more it’s going to cost you to catch up. Software upgrades are clearly a case of paying now or paying more later.

Dangerous Technical Debt

Technical debt accrued because of deferred or ignored software upgrades isn’t just expensive technical debt, it’s potentially disruptive and dangerous technical debt. As software ages, its dependencies get etched into it. Many IBM i shops today are still using very dated mission-critical Windows* applications or very old versions of IBM i. The longer that you postpone upgrading your platform, the more invasive and costlier you can expect the upgrade to be—and the longer it takes. And the longer an upgrade takes, the more disruptive it is to the business.

Dangerous technical debt comes due when one of the tangential parts of an application hosted on an old platform simply quits working. What happens if your shop is still on IBM i 6.1 and your third-party vendor electronic data interchange (EDI) package no longer supports that version? And what if that upgrade fixed a notable security exposure? What happens if you’re using a COM-based Windows application and a Windows update breaks a tangential third-party component? The cost of business disruptions like these is incalculable.

Achieving Software Wellness

Just as regular exercise and a good diet are necessary for personal wellness, regularly upgrading and refreshing your organization’s software is necessary for software wellness. Your organization runs under the assumption that its software will be available without fail. Without budgeting and planning for your organization’s software wellness, that may not be the case. To achieve software wellness:

• Recognize that software ages quickly. IBM i 7.2 will be five years old in May! You don’t need to replace it immediately, but set the clock now for upgrading within at least two years. You should also keep an eye on Windows desktops and servers. Windows 7 will be (gulp!) 10 years old in October.
• Don’t skip “free” upgrades. These are like the “free” butter a restaurant offers with its lobster tail entree. You paid for maintenance or support plans for those free upgrades—use them! Those updates add features and fix bugs. Staying current with minor upgrades usually makes major upgrades easier.
• Audit your software, including end-of-service dates. Evaluate each and calculate potential business disruption should something stop working. Don’t miss obscure or easily overlooked tangential dependencies. They count and even a minor component’s failure can bring the system down.
• Be especially attuned to critical security updates. In today’s heavily network-driven world, be especially mindful of important security updates. Security exposures (such as Equifax’s 2017 breach) happened because Equifax hadn’t upgraded its Apache Struts application in a timely fashion (bit.ly/2x1axDI).
• Have a plan. With a fresh audit in place, make a plan to start getting current. You may not be able to do it all in one year. That’s OK. Just know what you need to do and make a plan to do it.
• Don’t be a pioneer. While it’s important to keep your software upgraded, don’t go off the deep end and be an upgrade pioneer. When an upgrade is released, sit out the first rush to upgrade. When the dust has settled and you’re confident the upgrade itself isn’t faulty, then upgrade.
• Watch other technical debt. Software upgrades are important to avoid unnecessary technical debt, but there are many other ways to incur technical debt. As you are pondering all of the software your organization uses, give it all a critical review for technical debt—then start paying some that debt down. Future you will be thankful!

Squaring the Debt

Software upgrades are simply a fact of life. Don’t ignore staying current. The longer you wait to upgrade your software, the greater the technical debt you accrue. And the day will come when you have to square that debt.