The little legacy code that could: a fable of software ownership

This would have been much improved if the cute legacy system has been speaking a dialect of Latin found in ninth-century Bavaria, with a slang vocabulary developed for its specific problem. And insisted that everyone else use that dialect when speaking to it.

I am currently rewriting a 10 year old VB application, which is in web forms. That application communicates with AS400 DB2 database. I get to use as400 here and there.

My application is in .NET Core 2. There are some issues as anything IBM can be a pain in the ass to work with. Also, the as400 dev and me have a tremendous knowledge gap. I know everything new such as unit testing, proper source control, dependency injection, linq and ORM tools. However, when it comes to speed of queries he is much better at optimization. Since, he has worked with some ancient languages he has a better understanding of low-level programming.

Honestly, it is pretty interesting at what speeds the current tools allow us to develop applications. For example, he would need to set up the DB, then security, then applications, stored procedures, map parameters in code and so on. I can accomplish most of these things with an ORM like Entity Framework in less than an hour and have a working project, obviously depending on the scale of it. However, both approaches have pros and cons.

Having old legacy code is problematic. It is harder and harder to find developers and rates are going up as the BIG fish still rely on them and can pay more.

For anyone who wants to learn about working with and on a "legacy" code-base, check out Michael Feather's book "Working Effectively with Legacy Code"

In the beginning it goes over code smells and how to find refacing seams in your language of choice (C, C++, or Java) and then each chapter is a group of techniques you can use.

Working on a service that had both a very old monolith and some brand new microservices, I found it invaluable. I think the first lesson I applied from it was using pinning tests for safer refactoring.

It is indeed a conundrum.

Working in maintaining and supporting legacy software is both an absolute necessity for the business and a possible career dead-ending move for you. You're at the same time doing important work -- if not particularly interesting or groundbreaking -- and signalling to your employer "I'm not marketable enough that you must raise my salary or risk me leaving".

Working on legacy software can also be a dead-end when interviewing with some startups. Interviewers from MuleSoft once told me to change jobs and work on more interesting, high-profile open source tech stacks before interviewing again with them. (I did, but didn't try another interview with them because I later learned what they do isn't particularly interesting, either).

Some people do specialize in obsolete software and make it their niche, but I find in my country (not the US) the degree of success with this is overstated. For example, I know very few COBOL programmers who earn a lot of money. Most are in a lose-lose situation, earning average money and... working with COBOL.

> Owning the legacy software that runs the business tends to provide job security at your current job, but can hinder your professional growth at both your current job as well as any future jobs.

This became my issue with contracting. I had known expertise in one thing, but never a chance to work on another thing professionally. I could see the writing on the wall that this thing wouldn't be that competitive in the future, but the incentives to get out of it weren't there.