Ask HN: code we write today will be thrown out in the next 30 years
As a software developer, I believe that most of the code written today will be garbage in the next 30 years.
Do you agree?
Do you agree?
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.
I have a php system that has been going strong since 2005.
The compilation took hours, so hooks with an emebedded scripting language used to make changes to the system without recompilation.
I don’t think we’re unique in being in an industry where the things we create have a limited lifespan.
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.
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.
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 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)!
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.
"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 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.
Sometimes not even last 2 years
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.
Use C on the client and Java on the server to increase your chances.
If you're using NodeJs, make that 3
Early in my career, I worked on a Honeywell TDC3000 control system which was 20-30ish years old by that point.
Tell those on maintaining or even writing new programs using fortran, cobol and 370 assembler.
It depends I think.