I have code written 20+ y/o, which is still running in production at multiple places in the world. It's for non-trivial soft-realtime embedded system processing PBs of data in realtime, not some CRUD app which can be easily spit out by GitHub Copilot or ChatGPT.
But yes, every SW/HW/systems project should come with an expiration date.
From quick-and-dirty or throwaway, to extended longevity/support.
It's important to choose the tech stack, architecture, and SDLC accordingly.
e.g. don't use ecosystem with accelerated bit rot like nodejs/npm for long-term projects. Similarly don't use C++, Rust, etc. for one-off scripts or prototypes.
Same for Agile/Scrum vs upfront design/RUP/mini-waterfall.
Almost all code is lucky to survive more than 30 months, but then again, so what? Is the code that most software developers write essential to the continuation of human civilisation?
If we're being honest almost all of the code that's been professionally written in the past decade has been superfluous.
If you do want to write long-lasting code then the best option would be to write useful programs for yourself.
Way earlier than that. There's two ways I think about code:
1. The code I write is a response to what I currently understand of problem I currently have, using my current understanding of current tools. Expertise improves how big the "current" horizon is on understanding problems and tools, but the current-ness of the problem space and tool space are external factors. Either way, both personal growth and world changes (basically time) will and should invalidate code.
2. Code is an expensive liability against the Universal Bank of Entropic Chaos. We take on the liability of building and maintaining it so that we generate a complementary asset that does something we consider valuable. But there is always an initial price and compound interest to be paid. Expertise will reduce both the price and the interest rate, but neither can ever go to zero.
it's not necessary to have the product last 30 years. E.g. in car industry, tons of code is carried over in new products. If it works and does the job, why change it?
If the code is tied to a physical process, this will likely not change.
What changes is the sensor, it's transfer curve or the mean to communicate the reading, but how to treat the value does not change so much over time.
I wrote some Jboss 5 code in 2009 (ish) that JUST hit the end of Red Hat's Extended Life Support in 2022. JBoss 5 EoL was announced in 2016, but you can purchase 5-6 years of critical security fixes with Red Hat's ELS.
That's only 15 years, but in some industries maintaining a stable software configuration is mission critical. If the software gets changed/upgraded, expensive certifications have to be re-done (e.g. FAA's certification for aircraft software).
But that's only when changing the code is DRAMATICALLY more expensive than freezing. In most cases, you want your codebase to be evolving to meet the changing requirements of whoever needs the software.
The hard part is figuring out what code isn’t extremely ephemeral. Sometimes you create something hackishly and it just finds ways of surviving the test of time.
I'm not coding for 30 years (yet), but I have some code from 10 years ago that is still running and being used today.
The fun part: all code that had "fancy new technology" in it has been replaced over the years. The only code that has survived was written from scratch without any other dependencies. Most of it being vanilla Javascript (doing quite advanced calculations)!
As with most artifacts, survivorship bias will ultimately dominate.
Some code will prove itself to be unusually durable (parallel: the pyramids) or some will prove to be so useful that someone will maintain it (roads that have been used for 2,000 years).
Most does ultimately fade to time.
That said, I use code daily that folks wrote 20+ years ago. Not just continuous lineages like an OS kernel, but actual applications written decades ago and never updated since.
Likewise, while most web sites/applications I've built for clients probably only exist on a tape in a datacenter now, people still upload videos of games I created 15 years ago to Youtube.
Getting code to last is all a mix of innate durability, utility to others, and some luck. :)
There are 30 year old programs which still compile and run today but they do not depend on SSL and fast moving programming languages which break with every release.
Software has become the roman potery of the today's world.
I always like to think about the half-life of both code and documentation.
"this code has a half life of 5 years" means there's a 50% chance that it'll get thrown out within the next 5 years. 3-5 years is a pretty common half-life IMO
Likewise "this documentation has a half-life of 2 years" means this documentation will no longer be useful in 2 years.
Yeah I've written some things that have been running for 10-15 years in production (I'm not old enough to see things to 30 years yet). It's a very tiny portion, though.
I recently found out that code I wrote 15 years ago on a whim because I was frustrated about some inaccuracy in a rendering pipeline is the basis for one of the major components of a multi million user application.
I wrote that code on top of 10 year old code.
I’m sure it has changed over the years, but at some layer both my code and the now 25 year old code I based it on live on.
Most of the code I write is garbage the day I write it. I agree most of it will be unused in 30 years.
But some of it lives on, and you likely won’t know it when you write it.
More like the next three years. Most software has a short lifespan. A lot of software goes obsolete, or requirements change, before it ever gets released -- a negative lifespan in a way.
A few software systems have long lifespans: Unix, Windows, Oracle. Those have undergone continuous development and don't resemble their original versions when you compare the code.
If you want to work on code that will apparently live forever in production, try the IRS or the California DMV.
Wordpress started in 2003 and if you chose it back then, it's still kickin'.
I just checked the website of the first job I had out of college, in 2004, for a niche tech company in the auto industry. The java-based central auth system I put in is still in use (I can tell by view-source). If it's lasted this long, another 10 years shouldn't be too hard.
I have code I wrote thirty years ago that's still running, but of all the code I've written, that's a minority. Most of it is no longer being used.
In fact, most of the code you write will be garbage in 5-10 years. The problems for which we're building solutions tend to be very ephemeral, so therefore the solutions tend to be ephemeral as well.
There are hundreds millions of lines of code required to do extremely basic things in everyday computing. Most of it should be thrown out, but most will not be, it will just accumulate and bog us all down until it becomes unworkable to continue like this.
I've recently compiled my JSON parser with Borland Turbo C compiler (from 1989) on FreeDOS. It feels good to see the code builds with compilers covering 34 years. ANSI C is still remarkable.
But yes, every SW/HW/systems project should come with an expiration date. From quick-and-dirty or throwaway, to extended longevity/support.
It's important to choose the tech stack, architecture, and SDLC accordingly.
e.g. don't use ecosystem with accelerated bit rot like nodejs/npm for long-term projects. Similarly don't use C++, Rust, etc. for one-off scripts or prototypes.
Same for Agile/Scrum vs upfront design/RUP/mini-waterfall.