50 Legacy System Jokes Only Maintenance Engineers Truly Get

"What does this service do?" It has been doing it since 2011. That is all anybody knows.

The deployment instructions are a Word document. The Word document references a server that was decommissioned in 2016.

"Can we rewrite it?" We tried. Twice. Both rewrites are also legacy now.

The build script is a 400-line batch file. It works. Nobody touches it.

There is a server under a desk in the finance office. It runs payroll. It has 1,400 days of uptime.

"Who wrote this code?" The blame says Steve. Steve left in 2014. The function still has Steve's TODO comment on top.

Two kinds of engineers: Those who have run a binary they cannot rebuild from source, and those about to.

"The documentation is on the wiki." The wiki was migrated. The page is gone.

I asked about the database trigger. Three people looked at the floor. One person said: do not.

"Just add it as a feature flag." The feature flag system has 600 flags. Half of them are unreferenced. The other half are load-bearing.

The application was written for Internet Explorer. The application is still in production. The customers are still happy.

"Who has access to deploy?" Steve. Steve left in 2014.

I trust new code. I just trust code that has survived ten years more.

The function is 2,400 lines long. It has one comment. The comment says: do not refactor.

"It works." The four most dangerous words to say about a legacy system right before you have to touch it.

The shell script calls a Perl script which calls a Python script which calls a stored procedure. This is the export pipeline. It runs nightly. It has never failed.

"We have unit tests." The test file has been excluded from CI since 2018.

The login page has not changed visually since 2009. The login page handles 80 percent of revenue.

"What's the architecture diagram?" It is a whiteboard photo taken in 2015. The whiteboard photo has resolution issues.

The original developer is now a VP. The original developer does not respond to Slack messages.

"How does the cron job authenticate?" A service account whose password is the founder's middle name. From 2010.

A senior engineer is somebody who has politely declined to be the owner of three different legacy systems.

"Can you migrate this off the mainframe?" "What's the budget?" "Two weeks."

The database has a column called `temp`. The column has been there for nine years. It is required.

"The system is well-tested." The test is a customer calling support when something breaks.

I read the source code. The source code references a JIRA ticket from 2013. The JIRA instance was sunset in 2019.

"Why does the report take eight hours to run?" Because in 2008 the dataset was small enough that nobody worried about it.

The application server is named `apollo`. There is no apollo2. There was supposed to be.

"What's the upgrade path?" "There isn't one."

Every team has one binary they cannot rebuild from source. It runs in production. It has been working since the previous office.

"Just add a new endpoint." The routing file is 4,000 lines and ordered by date added.

The system was written in a framework that is no longer maintained. The framework's GitHub repo has been archived. The README links to a personal blog that is now a parked domain.

I once tried to add a unit test to a legacy module. Three weeks later I had a working mock for a database that the function did not actually use.

"Just put it in a Docker container." The binary requires a specific kernel version. From 2012.

The customer-facing app is modern. The back-office tool is from a different decade. The back-office tool is where the money is.

"Can we deprecate this endpoint?" One customer integrated with it in 2014. They are the largest customer.

A new hire asked about the design choices. The design choices were not chosen. They accumulated.

"The code is self-documenting." The code documents a problem nobody can describe anymore.

The CI pipeline has a step called `unknown_step` that has been failing silently for two years. Everybody has memorized to ignore the red dot.

I asked which version of the dependency we use. The answer was: whichever version the build server happened to have cached in 2017.

"What language is this written in?" "Three languages. And a stored procedure."

The data migration script was written for the original launch. The data migration script is still in the repo. It has been run, by accident, twice.

"Why is there a hardcoded IP address?" Because DNS was unreliable in 2011 and nobody got around to changing it.

The legacy system has a single point of failure. The single point of failure is also the person who knows how to fix it.

"We don't need to refactor." The codebase is one file. It has 18,000 lines. It is named `helpers.php`.

I do not always touch legacy code. But when I do, I bill for it.

The system was supposed to be replaced in 2018. The RFP for the replacement is still in draft.

"Can you just move it to the cloud?" It depends on a hardware dongle that is plugged into a desktop tower in the supply closet.

Some people fear horror movies. I fear inheriting a Perl codebase with no tests.

Working on a legacy system is basically: Getting paid to learn the decisions of people who do not work here anymore and explain those decisions to people who will not work here next year.