Legacy Software Modernization

There seems to be a continual tension in the software development lifecycle between upgrading to the latest development technologies and supporting legacy systems. Can a proper balance be found?

In arguments that range from the dialectic to the pragmatic to the dogmatic, there are no shortage of those in technology that are content to stagnate. Let’s break down some of the arguments against moving forward in technology and propose a principle for keeping organizations leaning into the future.

Argument: Don’t Break What isn’t Broken

There is usually a side arguing for supporting as large of a user base as possible. There may be business pressure to continue to support all existing users. (“But we have two Solaris users that are counting on us!”) This, then, puts a burden on the developers to bend legacy software to their needs in order to not upset users. This may prevent the use of new compilers but ensure that a wide historical platform base is supported.

Still, others resist upgrading legacy software technology out of fear disguised as pragmatism. Experts are established in their tools, and it is natural for them to feel isolated by new technologies. Even senior engineers may be reluctant to gain an equivalent level of fluency in the new technology. The team makes the argument that the downtime incurred by retooling can never be recovered. Even with supposedly superior new tools/languages/patterns!. Further, the new tools lack so much compatibility with the legacy software environment that to change would be to invalidate the established trust in the product, rendering the new release untrustworthy and, since the technology would be new to the development team, impossible to troubleshoot in a timely fashion.

Argument: Stay at the Forefront of Technology

But on the side arguing for advancement, cavalier attitudes paint a blue-sky future. The team breaks the back of their Software Development Life-Cycle (SDLC) and undertakes massive refactoring. There are promises that lines of code are to be reduced to mere fractions of their current selves! Run times diminished so much entire server architectures can be condensed down to run on a graphing calculator! There is the argument that the new tools make development easier, safer, and faster. Spend time modernizing code. Modernization will reduce the total cost of development and possibly improve security along the way. This, in turn, results in better overall software that will continue to grow its user base. (Even if both of the Sun users are not pleased.) The introduction of new development tools would provide an opportunity to refactor. Take the time to learn and “do it right” when constituent parts need re-architected.

Apply Principles

All of these arguments are valid. We must apply solid principles to these issues to remove our own biases and gain some insight into the ramifications of our upgrade decisions.

While I would not advocate trying to lead every technology trend, I suggest keeping your products and code modern. Accept that, unless you are a modern Luddite, technology marches on. Old operating systems, hardware, and languages will eventually reach End of Life. Technology will not wait for you to upgrade your skills. Progress marches on even if you do not fix your bugs. Every time you fail to convince your customers that you need to overhaul your legacy software, your competitors will be gaining ground on you. If you do nothing, your code will rot, and you will amass an insurmountable amount of technical debt. Keep patching and shoehorning, and you will turn a once graceful solution into a Big Ball of Mud. (Are you in need of help with Project Recovery?)

Principle: Accrue technical capital by taking the time to steadily continually improve your products and pay down technical debt.

Take, for instance, the case of a stable C++98 legacy software codebase. Through continual evolution in your software development lifecycle (SDLC), the code base is gently brought into C++11. From there, it was easier to integrate meaningful upgrades to its infrastructure that utilize features from C++14, C++17, etc., as those standards emerged. The upgrades were continual, meaningful, and paid down technical debt.

Upgrade compilers, change languages when appropriate, and keep an eye on users who deeply care about performance. Let your competitors stay behind and tend to their dying platforms. Reward your project with simpler code, maintainable code, elegant code, great testing, happy developers, a happy user base, and two disgruntled Solaris users.

Hellebore

2900 Presidential Drive, Suite 155

Beavercreek, OH 45324

(833) 694 8496

info@hellebore.com