IT is expected to correct defects within its software systems, but is often unable to keep up with defect backlogs due to the increasing complexity of aging software. As IT budgets continue to tighten, how can smart departments dig themselves out of this ever-deepening hole?
Photo courtesy of Simon Cunningham (Creative Commons – Modified)
| The crux of IT is that it’s always being asked to do more with less—even while its job gets harder and more expensive to do. Unfortunately, that is never going to be cheap—at least so long as their budget remains focused on merely putting out fires. |
If you work in IT, I’ve got a good guess as to where most of your budget is currently going. It’s the upkeep of your legacy software systems, right?
Of course it is—because it’s never anything else.
Unfortunately, most people see IT merely as the folks who keep the lights on—rolling out patch after patch, release after release, and update after update in the pursuit of keeping the company’s software systems chugging along. And while I’ll never argue that isn’t one of IT’s primary functions, it barely scratches the surface of all that it does.
The crux of IT is that it’s always being asked to do more with less—even while its job gets harder and more expensive to do. Unfortunately for the business, preventing an ever expanding (and ever tenuous) network of software from imploding upon itself is never going to be cheap—at least so long as the business (and the budgets they allocate) remains focused on merely putting out fires.
Ever heard of the term “technical debt”? It’s defined as the eventual financial costs of a system design; borne out over the course of its lifespan through a series of “payments” made on its upkeep. With software systems, these “payments” occur every time you patch a bug, release an update, or add a new functionality.
But therein lies the rub: whether you’re employing a dedicated testing team, implementing a department-wide quality assurance program, or developing newer software to replacing aging legacy systems, transformational initiatives ain’t cheap. And though it’s cheaper in the long run for the business to make the investment now, a lot of times it’s just easier to stick with the status quo than risk trying something new.
And if everything else were equal, this would almost be okay. But there’s another factor at play.
As legacy software ages and new functionalities are added, the complexity of the aging system increases exponentially—along with the risk of catastrophic failure. Older software often means more bugs, and more bugs mean more effort to fix (and, inevitably, more fixes put off until the next release). This means that, over time, an IT department is going to have to spend more and more to achieve the same level of overall quality. All of the sudden, the status quo isn’t so status anymore.
Remember that definition of Technical Debt I referred to earlier? This is the endgame: ever-tightening budgets, decreasing quality, mounting user frustration, and headaches. Lots and lots of headaches.
That’s what happens when you only attack the symptoms and not the disease. And while the latter path is more involved than the status quo, the ROI of undertaking this path is well worth it.
Granted, the real challenge is communicating that kind of ROI the business. It’s a nuanced, challenging task; but we’ve been doing it here for years. So if you’re tired of fighting fires and want to start preventing them, drop us a line so we can help you out. Even if you’re just looking for advice, we’re more than willing to talk!
Just remember, sooner is always better than later. That ever-increasing pit of technical debt isn’t going to get any more shallow.
Cheers,
Mike Hodge
Lighthouse Technologies, Inc
Software Testing | Quality Assurance Consulting | Oracle EBS Consulting
