Prisoner of Legacy Systems

At some point, old software installed, just has to go away. The million dollar question is when.

After recently experience of having a legacy system for about 8 years too long that prompted me to blog on this topic. I've seen the impact first hand with regard to project timelines, business climate changes, and constant tickets to the help desk. Project managers constantly asking, "Why does it take longer every year to do something simple?". - Really?

An online definition,

“A legacy system is an old method, technology, computer system or application program that continues to be used, typically because it still functions for the users’ needs, even though newer technology or more efficient methods of performing a task are now available.”

Those who are making these technology decisions are not typically directly affected by them. They’re looking at out-of-pocket cost versus total cost of ownership. While this takes place, I’m more concerned with all the time involved to resolve the same repeatable problems along with trying to figure out an escape from the legacy prison. So what do I do? Just keep answering those same ridiculous rhetorical questions of "Why does it takes so long and why is it so difficult" with a calm soothing voice, "Because you incurred Technical Debt".

During the course of 8 long years of projects, the project team took shortcuts due to a variety of reasoning, such as lack of technical ability, pressure of meeting project deadlines, or just flat-out lazy. You can imagine over time, these poor decisions accumulate huge backlogs of inefficiencies that keep getting kicked down the road. At some point, Peter may not let you rob him while Paul needs an early payment.

While the cost of maintaining an old system may indicate that a change is needed, it is also possible to spend more than necessary on a new solution. We need solutions that help us stay competitive, however wasting money on software upgrades, can be unnecessarily as it increases Technical Debt. When the old systems can’t keep up with the business demands or changes, it's time to replace. In the absence of due diligence, it is not always clear which option of replacement or upgrade, is best.

Most replacement systems at minimum, need to provide marginal benefits over any legacy system being replaced to justify the cost. Poor legacy software replacement decisions happen when technology decisions are not aligned with business requirements and strategy. Have you had lunch with your Enterprise Architect lately?

So let's encourage our product owners to make conscious decisions on if the economics justifies the cost of the incurring technical debt. Not all technical debt needs to be repaid as one can live with issues on a product nearing end of its life. Just like your payment of financial debt, it is good stewardship to first repay the "high interest" technical debt. It is preferable that technical debt be repaid incrementally (like making a monthly mortgage payment) through use of practices such as peer reviews, refactoring, continuous integration, and automated testing.

So what's your strategy for technical debt prioritization on your portfolio prison? A general rule of thumb could be based on comparing the degree of current value of business capabilities against the degree of business value that the system fulfills for future business needs. This may not get you out of an early prison sentence, however maybe, just maybe, feeling liberated removes illusions of being in one.

“That which we manifest is before us; we are the creators of our own destiny. Be it through intention or ignorance, our successes and our failures have been brought on by none other than ourselves.”
― Garth Stein, The Art of Racing in the Rain