A recent dinner companion shared a story of his management’s plan to ensure continuing maintenance and viability of a large and rather old mainframe system he supports for a government agency. His specialty is writing, maintaining, and modifying assembler code for the specific hardware host machines and as you can guess, there aren’t many people left around who already know how to do that kind of work. What’s more, they tend to be older, expensive, curmudgeonly, and not always up to writing code in the most modular, clear, and approachable way.
OK, I’ve seen that, and I grant it can be a problem, but the gentleman I was speaking with wanted nothing more than to rationalize everything he could, as I would. He faces two major problems.
The first is that the code is decades old and has been hacked over with little thought to rationality, structure, consistency, clarity, or anything else much helpful. It also contains self-modifying code which is difficult in some cases even to recognize, much less to maintain. Modern processors often won’t even support such shenanigans.
The second is that the agency’s managers want to convert the whole thing to Java so they can hire a bunch of young kids right out of school to maintain it at a lower cost, and possibly with less undesirable feedback (someone who’s been around for a while is likely to be less afraid to tell you things that are true but that you nonetheless don’t want to hear). This is all well and good, though we know that nine women can’t have a baby in a month. This is another way of saying that throwing programmers at a problem isn’t always the way to solve it, and often proves to be counterproductive.
Older, mainframe systems often stay in use for a long time because of precisely the reasons described. The FileNet systems I wrote in the early 90s included an automated terminal component that had the ability to log into and navigate through a legacy mainframe system, then screen scrape the results and incorporate them into the FileNet system’s (Oracle) database. If you can use such a capability to migrate all of the legacy system’s data then great, but if not that system may remain in place.
There was a further impetus to replace or upgrade such systems in the run-up to the Y2K rollover, and I knew some folks who made good money around that time. It turned out to be a non-event mostly because critical code usually didn’t include problematic date calculations (none of the real-time control applications I was writing at the time had a problem, some Wonderware HMI archiving routines proved susceptible but were easily patched), and because most of the mainframe code was either successfully modified or the affected systems were scrapped and replaced entirely. There are legitimate reasons for some legacy systems to still be in use, but in some cases I’m sure they remain merely because of convenience or inertia.
As I noted the agency’s managers want to implement a new system in Java, which I support, but what I don’t support is how they intend to do it. Rather than figure out how it works and reengineer it so it makes sense, particularly while they still have access to people with the experience to help do so accurately and completely, they are undertaking a major effort to write a tool that will translate the code as is, self-modifying operations and all (I was told they’ve figured out how to do this). So, even if they are successful with this project, which itself consumes resources and incurs a respectable amount of risk, they will then continue to be burdened with the same mountain of unmaintainable spaghetti logic they had when they started. That will consume its own resources and incur its own set of risks.
Sure, you can get new graduates who know Java, but how many are going to be able to tease apart the morass to make meaningful and timely changes? Agile and Scrum processes don’t make that kind of code more manageable any more than recasting it in a more modern, higher level language does. (Making fixes as they are identified is better suited to a reactive, Kanban style anyway.) It’s like eating all the food in a hot air balloon in hopes of making yourself heavier so you can get it to descend. You didn’t make the balloon heavier, you just moved the food. And you likely made yourself sick in the process. Moreover, how many of those young people will stay to fight with it when all of their friends (those who could get jobs, anyway) are writing new code under more reasonable management guidance.
Sometimes it isn’t the tool or the language or the platform that is the problem, it’s the underlying logic. You can fail to solve a customer’s problem with any kind of system and you can solve a problem with almost any kind of system. Some tools and platforms are clearly better than others for certain applications, but if you aren’t solving the right problem you’re kind of missing the point.