Elisabeth Greenbaum Kasson asked me recently for advice on working with legacy applications. Check out her piece on it. Here’s the full reply I sent to her in email:
– The steps someone could take to get themselves up to speed on their employer’s legacy software.
– How this knowledge can make them indispensable (I know that term is relative)
– Why this type of expertise is so necessary, especially when it comes to integrating said software with new and/or evolving products.
When it comes to “dealing with legacy,” there aren’t that many good options. We often think of “legacy” as software that must be changed but that we’re afraid to change. If you’re not afraid to change it, you often just think of it as “our software.” Legacy has this connotation of it being risky, scary, or maybe just boring.
If someone wants to go down into the mines of legacy management, the first thing I’d recommend is doing some history work to find out why the legacy system in question was created, what it’s currently used for, and, hopefully, who the current stake-holders/owners are. You’d be surprised – or maybe not! – how often some or all three of those are totally unknown: with unknown stake-holders, I sometimes hear tale stories of IT departments just shutting down systems and waiting to see who calls them.
Understanding the why, what, and who of a legacy system will tell you most of what you need to know when it comes to managing it. Further up the management chain, having a good grasp of and on portfolio management is valuable. Given the why, what, and who, you should be able to prioritize any given “legacy application” relative to another with respect to funding and attention. Is fixing the application that’s used to schedule office party birthday cake orders more important than the application used to re-order plungers for the warehouse bathrooms? You won’t know between cakes or plungers if you don’t do portfolio management.
The other aspect is simply learning the technologies you need – operationally, programming, and sometimes physical management – to keep the thing up and running and to modify it. This might mean learning, for example, about operating systems for mainframes, AS/400, UNIX, older versions of Windows, and sometimes even exotic things like OS/2. There’s dozens of programming languages out there, and you’ll need to learn not only the appropriate “old” language, but how the build, version control, and project management tools around those old stacks function.
For more, I wrote about dealing with legacy in my cloud native journey booklet last year.