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

This made me think of an enterprise-software version of Wreck-it Ralph. I'd watch that, but I'd be part of a small audience (though arguably, Tron qualifies).

A small audience, but one with a good amount of disposable income.

This is one of those interesting paradoxes that I haven't figured out yet.

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.

Getting on to projects that are intended to replace legacy software tends to get you a lot of positive visibility politically and the ability to learn new technology and skills. If the new project fails there tends to be little fallout from the failure, since so many people are attached to the project at all levels. The goal posts will move so it can be reframed as a success.

If legacy software fails it usually means long hours and a lot of people nervously asking you when it will be fixed.

Unfortunately there's just not a lot of value to being able to put on your resume that you're an expert at an older language that nobody has heard of, built on an in-house framework that will never be used outside of your current company.

> Unfortunately there's just not a lot of value to being able to put on your resume that you're an expert at an older language that nobody has heard of, built on an in-house framework that will never be used outside of your current company.

I think this is, fortunately, only approximately true. Most of my career to-date has involved exactly this kind of work and it's certainly not true that there's no value in it, even on a resumé or mentioned in a job interview. And certainly some non-zero amount of people derive considerable value from exactly that kind of experience as some non-zero number of employers or customers need someone with it.

And, in a lot of ways, working on legacy systems can be both immensely fun and rewarding. Even just incremental improvement in or around such systems can itself be immensely valuable, e.g. setting-up automated builds or deployments, adding integration tests (to make future refactoring easier and safer), or rewriting or replacing a key portion of the system using newer tools or with a better design made possible due to the wisdom accumulated by a system performing real work over a significant period of time.

If anything, it's a pretty pragmatic view about the high frequency with which new systems intended to replace legacy ones fail to do so.

Certainly applications can be supplanted or replaced, and often are, at the discretion of users and customers.

But 'living' (running) systems can often only be successfully replaced in the manner of the Ship of Theseus.