Erik Dietrich, an IT consultant in Michigan, has a story about a state government agency that replaced its green-screen system with Windows and online forms--it resulted in a slower, clunkier, more hated system than the obsolete terminals and was practically obsolete itself by the time it launched.
There are lessons to be learned, Dietrich noted, for when your employer makes you use outdated software development tools. He calls them "zombie" languages and tools, as explained in his February 2018 blog post about Microsoft Visual BASIC, written for his client SubMain Software, which makes code analysis and review products. With examples such as the perpetually not-dead-yet COBOL, "Luckily, programming languages can enjoy long, fulfilling, and healthy deaths as zombies," he wrote.
Dietrich, asked about the scope of the problem this week, began his answer with an audible gasp of exasperation. "Oh my god, I'd say it's quite pervasive... what gets all the press in the industry is the [latest] but I imagine there's a sizeable silent majority of developers working on obsolete technology," he said.
Last week's Cloud Foundry Foundation report further illuminated the ongoing use of non-trendy environments such as C and even assembly language. Dietrich offered his advice to developers who probably haven't touched such packages since college.
"The first thing would be, is this in your wheelhouse or background or not? If it's just dusting off something you are familiar with--like for me, I used to do VB6 back in the day--the first thing I'd probably do is go back and see: Do I have anything in this past language I can dig up and work on, or can I dig up any of the past resources I used to have?"
"I would go and raid places like half-priced bookstores and library book sales to look for old versions of programming books. That would probably help prime me for the work."
"From a tactical perspective, the thing I think to do there is try to get your feet wet by picking out relatively simple features that'll just require changing a few lines of code. You can get into the code base minimally invasively and get to know it," he continued. [Author's note: Taking some known-good code, changing things, and seeing what effect it had is how I practiced Applesoft BASIC in the 1980s.]
Or, rather than starting with new features for an old code base made with old tools, "See if you can pick some bugs off the backlog pile," Dietrich observed.
"Frankly if an organization is taking a developer and saying, 'Go pick up a 15-year-old language that you don't understand and implement a major feature,' there's something wrong with that organization."
What about integrating old programs with other systems? "Usually the thing I would suggest that a group or an individual developer should do there is, you want to design the other systems in such a way to be a little bit defensive against that outdated application, or robust might be a better way to put it--you want to insulate yourself as much as you can from it," he explained. "If you can, partition the old system's functions up into groups so you can start replacing it a slice at a time. So over the course of a couple of years, piece-by-piece you replace the whole thing."
Automated unit testing can be a lifesaver if you inherit code from another programmer who long ago left the building. It's the concept of testing tiny sections of code individually, rather than testing the whole application at once, Dietrich said. That was not possible in the days of green screens, but today it helps prevent games of whack-a-mole with your bugs. Amazingly, "I've read about people figuring out ways to do that in COBOL or even in Microsoft Access applications," he said. "You can be creative with ways to modernize your approach even if you can't modernize the stack."