Not so much code, but there was a shell script I wrote at a former company about a decade ago as a quick stop-gap to validate static file checksums in Akamai against a code deployment manifest and AFAIK it is still being used today and I don't even work there any more. It's just bash so it should be hopefully maybe super easy to fix when it breaks.
I wouldn't be surprised if a lot of people have a similar answer! I suspect my longest lasting code is either a quick and dirty shell script or a throw away prototype that ended up in production. I wonder how often the code we obsess over for quality persists versus, say, the code we build in response to a timely, but perhaps less high profile, business need. I'm curious what actually drives longevity.
It's not the longest running software in the world but hey... in 2013 I have written some software for one of the world largest tubelines. It took me around 2 months (and even that was causing pesky manager to moarn I overengineered the thing). It was written in C++ and I never had a chance to properly test it since operations started around year later and I left soon after, but my colleagues told me recently it's running well and staff rely on this quite heavily ;)
I've got 10 year old code still running because the SaaS product I built back in 2013 is still running. I don't think it will be in 5 years, and that feels about right in terms of lifetime of code. If you write a successful product, the need for it should keep the code alive until tech advances so far past your original stack that what was once new and innovative is old and legacy... and then the product is either sunset or re-platformed. So if your code lives anywhere in the 10-20 year range, that is not too shabby.
The first project I worked on as a solo backend dev is still in production. God knows how we won that tender. I was a 20-year-old clueless university dropout that definitely shouldn’t have been trusted, working for a boutique agency operating out of a converted barn out the back of some house.
It is a scheduling system for a department at a major public hospital in the area.
It’s still one of the projects I’m happiest with. Despite subsequent developers making a bit of a mess of it, it is a nice piece of software. And, compared to the rest of the stuff in health system, is it a shining beacon of hope for generations to come.
As I’ve progressed and started working for some bigger companies, I’m incredibly impressed by what we all, myself included, did with so little.
As an intern at a social services department circa 1997, I wrote some COBOL code that improved the way that a certain calculation was made and eliminated a bunch of processes. (It was calculated with about 20 steps due to people just pasting random crap on top of random crap over 25 years)
I ran into my old boss, who was a family friend, and he told the story that they used that as an example to improve other stuff, and that had saved a few million bucks over the years (iirc they paid for CPU cycles). It was still running as of 2020!
I wrote Half-Life 2: Sandbox, which was the first implementation of LuaJIT in the Source Engine. Planimeter beat Team Garry by years because Garry Newman modified his implementation of Lua for Garry's Mod.
The examples of how to properly integrate Lua into a larger commercial engine have been reused by my team for over a decade and used by larger teams who are on Steam as well as hobbyists.
We wrote a game engine called Planimeter Game Engine 2D that's also over a decade old which has tons of reference code that's easily accessible for game engine engineers and game developers that has advanced concepts like high tolerance client-side prediction down to dial-up connections and a UI compositor with CSS 2.1 features.
My software firm Andrew McWatters and Co., has an internal codebase called myapp which is also many years old and serves as a base for delivering web services to clients leaning on experiences from dozens from businesses including some in finance and healthcare to deliver solutions compliant with federal standards.
Good software lasts longer than bad software because it's useful, and doesn't chase trends, it defines them or stands apart in ways no one else's software does.
In undergrad, I wrote a Gulp plugin (a Node build tool) to run shell scripts. The added value was the ability to connect the script's stdin/stdout into the Gulp pipeline.
I wrote it in a weekend, just as a one-off while I was learning Node and procrastinating my other studies.
Today, it gets just under 30k weekly downloads. Which isn't a ton, but it shows that it's still being used.
After I got a real job, I found it in an internal third-party repo. Apparently some contractors built a site with it years ago.
If you live in US / Mexic and you use a Tiburon locker renting system (https://www.tiburonlockers.com/lockers-ele.html) to store your items while in a venue/location then you're using code I wrote between 2008-2010. Everything you see in there and more (like iceberg, what you see is only 10%) is written in Delphi with PostgreSQL as DB. Behind the scenes is just a Windows XP running my app in full screen (KIOSK mode).
Also if you drive a Mazda RX-8 (J64/J61J/J61A internal name) from 2007 that has immobilizer feature (back then it was an opt-in feature, nowadays every car has immobilizer by law) then the code running immobilizer feature was partially written by me between 2005-2006.
Software written in '98 on Oracle 8i/Sun/Solaris. Mostly SQL, PL/SQL & shell scripts. Still running even after db and os upgrades in 2023. It was mosly a database for online and batch transaction processing that fed a data warehouse and include the Extract-Transform-Load pipeline.
The reason for the longevity is the focus on extreme performance by focusing on I/O by utilizing the database and parallelism offered by the platform. Also, our coding language choices were pragmatic and are still supported. So, even with all the db and platform version upgrades, the code still runs.
I was one of the original authors of ds_cinder (a multimedia framework for building interactive designs.) it’s been actively developed since 2012 and has been used to make hundreds of interactive displays and experiences. Some features may seem normal place today, but there weren’t general frameworks with pdf, video playing, amx interface, multitouch support, and a ui engine built for touch screens back in 2011-2012.
I've been in the IT racket for over 30 years, so maybe I have an unfair advantage in terms of candidates.
I helped rewrite FIS (RSTS) as XENTIS (VMS) for Park Software in the early 1980s and worked on it for over a decade. It lasted as long as VMS did. This was the prototypical "report writer" / wizard.
I wrote a logistics system for a nonprofit on donated VAX hardware. That lasted a decade before Y2K doomed their accounting system (VAX don't care about no steenkin' Y2K!) and both were replaced together.
I wrote a procmail guide (documentation) and a web page with a javascript-based .procmailrc wizard that rattled around the internet for a while.
I've got various pieces of automation which have been ported to different systems for as long as two decades (I don't think I have anything currently running which is older than that).
I invite you to view the repos I have pinned at GitHub: https://github.com/m3047/ although none is older than 2019.
I seem to be building a command-line based federated SIEM leveraging DNS and Redis. At this point I don't know if it will ever see the light of day in terms of wider availability, haven't found anyone else who's onboard with this level of sedition (yet).
I've built other software which was popular for a short while.
I'll offer an honorable mention for http://twiki.org/ as I used to curate a distribution. I'm still personally running the version based on the Dakar release from 2006. I've patched a couple of security issues and made some small changes due to changes in Perl in that time.
So what makes code last?
It's not a beauty contest. It solves a problem, but you can solve the problem without it. It doesn't sit astride a shear layer. It inspires confidence in terms of predictability. It offers useful internal telemetry or other mechanisms which allow that confidence to be tested, explored, or extended. Oftentimes it doesn't solve THE problem, but is composable to solve various problems. It doesn't chase trends (XENTIS pretty much filled out out every useful feature we could think of in its niche, but it stayed in that niche). It might be personal bias, but configuration is declarative or at least machine parseable and accessible (so you can compare configs over the last decade or more).
I wrote an Assetto Corsa server plugin for the ACRL racing league which enforced track limits. The initial commit was in 2016, and to my knowledge it's still in use.
I think that the biggest factor in code longevity is serendipity. You wander into a project that will find the right user interest and some kind of sustainability model that supports its maintenance and continued use. This could be getting into a successful commercial software product, an enterprise solution that might just turn into a legacy, or some vibrant open source community.
My oldest code that I myself still use in production is probably some Python web services first prototyped around 2009 and then refactored several times including the port from Python 2.x to 3.x, which we deferred until 2018-2019. It is still in use because we keep finding use for it in funded projects. The Python language and hosting environments have been stable enough to keep it running with minimal externally-forced maintenance.
I might have had some older shell scripts that were in personal use for longer periods, but I've found myself retiring them one after another rather than trying to maintain them anymore. This included lots of my own "paperless office" kinds of tasks to acquire, convert, display, or otherwise manipulate various document and image files. I also used my own custom backup tools and email replication strategies for a very long time before begrudgingly moving to contemporary tools.
With other open source contributions, it's harder to say how long something lasted. Some of my C code ended up in grid computing libraries that might have also gone for almost 20 years, but I suspect it fell into disuse at least 5 years ago.
I also helped arrange some work on SSLeay, which later forked into OpenSSL, but did not author code changes myself.
Through my job, I was a bleeding edge user of a lot of Linux features and tried to provide good bug reporting, but did not contribute as an author. This included early SMP support, large file support, kernel-level GPU support, and various wireless and wired networking drivers.
My earliest open source engagement was as a beta tester for XFree86 2D drivers around 1994 while in college. I did a bit more of this with early 3D driver testing at my first job. I may have contributed some register dumps and other hardware info, but still would not say I authored any of it. Also as drivers are hardware specific, I don't know how long it took for my efforts to fully dissipate.
1986 Totalizer display system betweem Kentucky Utilities and Tenn. Valley Auth. ran for 15 years with no failures or reboots on an Imsai Intel 8080. Not complex but included an error correcting protocol.
It's a "single page app". Using jQuery. Python backend.
I truly hope nobody else ever has to work on it (now there are real single page libraries) but it still works and has been going like a charm over a decade and the users like it.
Every year I think maybe I'll redo it using Vue or something but never do.
a simple application that records the physical position of document folders for a law firm. it backups via a cronjob that sends an email with a zipped copy of the sqlite db, and will be 10 y.o. in a couple of years.
it has literally 1 user which finds it perfect and don't want it changed in any way, and I actually think it's mission critical at this point.
In 2002, I wrote a CMS in Python and later Zope 2, in a tiny company with 3 SWEs. At a given point, it was used for internal sites in 20 banks, a couple of 5k+ employees companies and a division of Deutsche Bank that managed investment funds. I left that company more than 10 years ago, and Zope 2 itself has reached end of life years ago, yet that initial codebase has seen quite a few migration but it is still alive. I connected again with the CEO of that tiny company, which has grown a bit but it was always a lifetime gig on (his) purpose and not a growth or die startup.
I think they are finally going to put it to grave, after a long discussion / brainstorming about AI and the impact on their main product (now no longer a CMS, but a low-code platform for SMEs).
There's some code I wrote 30 years ago that's still running inside a text-based, multiplayer, internet game (LPMUD). I wouldn't say it's useful, per se, but it'll probably continue to run for at least several more years.
36 comments
[ 3.1 ms ] story [ 90.7 ms ] threadNext up would be random ETL scheduled processes in back-offices.
It is a scheduling system for a department at a major public hospital in the area.
It’s still one of the projects I’m happiest with. Despite subsequent developers making a bit of a mess of it, it is a nice piece of software. And, compared to the rest of the stuff in health system, is it a shining beacon of hope for generations to come.
As I’ve progressed and started working for some bigger companies, I’m incredibly impressed by what we all, myself included, did with so little.
I ran into my old boss, who was a family friend, and he told the story that they used that as an example to improve other stuff, and that had saved a few million bucks over the years (iirc they paid for CPU cycles). It was still running as of 2020!
The examples of how to properly integrate Lua into a larger commercial engine have been reused by my team for over a decade and used by larger teams who are on Steam as well as hobbyists.
We wrote a game engine called Planimeter Game Engine 2D that's also over a decade old which has tons of reference code that's easily accessible for game engine engineers and game developers that has advanced concepts like high tolerance client-side prediction down to dial-up connections and a UI compositor with CSS 2.1 features.
My software firm Andrew McWatters and Co., has an internal codebase called myapp which is also many years old and serves as a base for delivering web services to clients leaning on experiences from dozens from businesses including some in finance and healthcare to deliver solutions compliant with federal standards.
Good software lasts longer than bad software because it's useful, and doesn't chase trends, it defines them or stands apart in ways no one else's software does.
I wrote it in a weekend, just as a one-off while I was learning Node and procrastinating my other studies.
Today, it gets just under 30k weekly downloads. Which isn't a ton, but it shows that it's still being used.
After I got a real job, I found it in an internal third-party repo. Apparently some contractors built a site with it years ago.
Also if you drive a Mazda RX-8 (J64/J61J/J61A internal name) from 2007 that has immobilizer feature (back then it was an opt-in feature, nowadays every car has immobilizer by law) then the code running immobilizer feature was partially written by me between 2005-2006.
The reason for the longevity is the focus on extreme performance by focusing on I/O by utilizing the database and parallelism offered by the platform. Also, our coding language choices were pragmatic and are still supported. So, even with all the db and platform version upgrades, the code still runs.
https://github.com/Downstream/ds_cinder
I helped rewrite FIS (RSTS) as XENTIS (VMS) for Park Software in the early 1980s and worked on it for over a decade. It lasted as long as VMS did. This was the prototypical "report writer" / wizard.
I wrote a logistics system for a nonprofit on donated VAX hardware. That lasted a decade before Y2K doomed their accounting system (VAX don't care about no steenkin' Y2K!) and both were replaced together.
I wrote a procmail guide (documentation) and a web page with a javascript-based .procmailrc wizard that rattled around the internet for a while.
I've got various pieces of automation which have been ported to different systems for as long as two decades (I don't think I have anything currently running which is older than that).
I invite you to view the repos I have pinned at GitHub: https://github.com/m3047/ although none is older than 2019.
I seem to be building a command-line based federated SIEM leveraging DNS and Redis. At this point I don't know if it will ever see the light of day in terms of wider availability, haven't found anyone else who's onboard with this level of sedition (yet).
I've built other software which was popular for a short while.
I'll offer an honorable mention for http://twiki.org/ as I used to curate a distribution. I'm still personally running the version based on the Dakar release from 2006. I've patched a couple of security issues and made some small changes due to changes in Perl in that time.
So what makes code last?
It's not a beauty contest. It solves a problem, but you can solve the problem without it. It doesn't sit astride a shear layer. It inspires confidence in terms of predictability. It offers useful internal telemetry or other mechanisms which allow that confidence to be tested, explored, or extended. Oftentimes it doesn't solve THE problem, but is composable to solve various problems. It doesn't chase trends (XENTIS pretty much filled out out every useful feature we could think of in its niche, but it stayed in that niche). It might be personal bias, but configuration is declarative or at least machine parseable and accessible (so you can compare configs over the last decade or more).
My oldest code that I myself still use in production is probably some Python web services first prototyped around 2009 and then refactored several times including the port from Python 2.x to 3.x, which we deferred until 2018-2019. It is still in use because we keep finding use for it in funded projects. The Python language and hosting environments have been stable enough to keep it running with minimal externally-forced maintenance.
I might have had some older shell scripts that were in personal use for longer periods, but I've found myself retiring them one after another rather than trying to maintain them anymore. This included lots of my own "paperless office" kinds of tasks to acquire, convert, display, or otherwise manipulate various document and image files. I also used my own custom backup tools and email replication strategies for a very long time before begrudgingly moving to contemporary tools.
With other open source contributions, it's harder to say how long something lasted. Some of my C code ended up in grid computing libraries that might have also gone for almost 20 years, but I suspect it fell into disuse at least 5 years ago.
I also helped arrange some work on SSLeay, which later forked into OpenSSL, but did not author code changes myself.
Through my job, I was a bleeding edge user of a lot of Linux features and tried to provide good bug reporting, but did not contribute as an author. This included early SMP support, large file support, kernel-level GPU support, and various wireless and wired networking drivers.
My earliest open source engagement was as a beta tester for XFree86 2D drivers around 1994 while in college. I did a bit more of this with early 3D driver testing at my first job. I may have contributed some register dumps and other hardware info, but still would not say I authored any of it. Also as drivers are hardware specific, I don't know how long it took for my efforts to fully dissipate.
It's a "single page app". Using jQuery. Python backend.
I truly hope nobody else ever has to work on it (now there are real single page libraries) but it still works and has been going like a charm over a decade and the users like it.
Every year I think maybe I'll redo it using Vue or something but never do.
it has literally 1 user which finds it perfect and don't want it changed in any way, and I actually think it's mission critical at this point.
I think I have a phone call to make next week...
Hard to beat php and c++ when it comes to that. Write once, run anytime for decades
I think they are finally going to put it to grave, after a long discussion / brainstorming about AI and the impact on their main product (now no longer a CMS, but a low-code platform for SMEs).
https://en.wikipedia.org/wiki/LPMud