Ask HN: What is your longest lasting code?
Which of the software you authored continued to be useful the longest? What do you think caused it to last longer than other software you've written?
36 comments
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.
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.
Somewhere around 1990, I wrote a system in Turbo Pascal to monitor and record the results from a PLC used to calibrate large water meters for the City of Chicago. I had a cooperative multi-tasking system that I used to keep everything updating a GUI while doing all the other work.
Somewhere around 2010, they contacted me because they had a problem with it when they replaced the computer with a newer system. It turned out they had the parallel input cards swapped, and it was put back in service. As far as I know it's still in service.
It's quite possible that thing will outlive me. Why? Because it's tied to hardware that works and does economically important work.
Somewhere around 2010, they contacted me because they had a problem with it when they replaced the computer with a newer system. It turned out they had the parallel input cards swapped, and it was put back in service. As far as I know it's still in service.
It's quite possible that thing will outlive me. Why? Because it's tied to hardware that works and does economically important work.
I wrote the postal game Quest back in 1989-1990, a 1,000 player postal game. 40,000 lines of Turbo Pascal. Others came after and fixed some of the bugs and it's now run over the internet. https://kjcgames.com/quest/quest.htm
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.
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.
Over 25 years ago I wrote a package in GNU Emacs (ielm) that, as I was chuffed to learn from a HN thread recently, is still in widespread use.
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 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!
Well, 50 years ago when I started assaying caustic soda cargoes, bureaus like ours were not yet using computers for this in the chem lab.
The bench technique was not as repeatable as I needed to begin with, but the easy calculations were identical to how it had been done using slide rules, only electronic calculators were the modern replacement.
The fourth decimal place really maks a big difference when you've got thousands of tonnes.
There was one caustic plant where they had a very specialized lab apparatus that allowed better precision, but we were not going to be able to adopt that approach worldwide in our independent labs.
I figured out a way to easily reproduce the results using ordinary apparatus, but the calculations were far too hairy for most bench operators to adapt to. And that was with calculators, nobody would have ever done this with slide rules.
So I wrote a little Basic program on the Commodore VIC20 that we had in the office just to experiment with. With 20/20 hindsight I was the first and only programmer at this particular multinational at the time.
Then it was a breeze to just assay the easy way on the bench, type in the readings to the VIC20 and out came the result.
Ended up leaving the company to build a lab in another port before this could be deployed elsewhere, did configure the code for a few different platform Basics before the IBM PC became so common, and used it myself ever since whenever I need to break out the big guns to settle a dispute or something.
One of the reasons I think it lasted so long for me is because it solved a problem that existed many decades before I came along with a systems approach that included code for the first time in history.
The bench technique was not as repeatable as I needed to begin with, but the easy calculations were identical to how it had been done using slide rules, only electronic calculators were the modern replacement.
The fourth decimal place really maks a big difference when you've got thousands of tonnes.
There was one caustic plant where they had a very specialized lab apparatus that allowed better precision, but we were not going to be able to adopt that approach worldwide in our independent labs.
I figured out a way to easily reproduce the results using ordinary apparatus, but the calculations were far too hairy for most bench operators to adapt to. And that was with calculators, nobody would have ever done this with slide rules.
So I wrote a little Basic program on the Commodore VIC20 that we had in the office just to experiment with. With 20/20 hindsight I was the first and only programmer at this particular multinational at the time.
Then it was a breeze to just assay the easy way on the bench, type in the readings to the VIC20 and out came the result.
Ended up leaving the company to build a lab in another port before this could be deployed elsewhere, did configure the code for a few different platform Basics before the IBM PC became so common, and used it myself ever since whenever I need to break out the big guns to settle a dispute or something.
One of the reasons I think it lasted so long for me is because it solved a problem that existed many decades before I came along with a systems approach that included code for the first time in history.
Life Insurance core code (ANSI C). So contracts closed now have to work for 60 years or more.
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.
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.
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.
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 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 ;)
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).
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).
Back in 2000-2001 I wrote a new compiler and linker for a cross-platform Visual Basic workalike called REALbasic. In 2016, the company contracted me to help out with a major new language feature they wanted to introduce, so I got a good look at the codebase, and most of what I'd written was still in use. (This inspired both pride and horror!) They have since replaced the code generator backends I wrote with LLVM - an eminently sensible decision - and they've renamed the product "Xojo", but most of what I built is still running.
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.
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 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.
https://github.com/Downstream/ds_cinder
https://github.com/Downstream/ds_cinder
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.
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.
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.
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.
I think I have a phone call to make next week...
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...
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.
https://en.wikipedia.org/wiki/LPMud
https://en.wikipedia.org/wiki/LPMud
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.
I suspect it’s preceded by the comment
# quick and dirty hack, please, please, please replace this before it goes to production
2011-2012 I wrote an inventory management system.
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'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.
I build an automated VBA code in a American Bank to automate daily reports on daily operations. Inefficient but it was the cheapest and only software that pc was able to run. It still working.
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 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).
Oracle stored procedures run by cron jobs. Ran for 5 years with no problems.
Probably code for the servers of a big-ish commercial online game. I haven't logged on and played that game myself for like a decade.
Next up would be random ETL scheduled processes in back-offices.
Next up would be random ETL scheduled processes in back-offices.
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 worked on a product about 25 or so years ago that is still sold, maintained and in active use - there will be bits of my code in there somewhere.
I wrote a bunch of C and VBScript in the 1990s that is still in production.
I helped familiarize a new employee with said code.
I wrote that code before they were born.
I helped familiarize a new employee with said code.
I wrote that code before they were born.
Custom email client written 10 years ago. It stopped spam and reminds me to write down ideas.
Reason is obviously the language.
Hard to beat php and c++ when it comes to that. Write once, run anytime for decades
Hard to beat php and c++ when it comes to that. Write once, run anytime for decades
I build a website in 1999 for a company which remained online unchanged until ~2019.
I guess some monitoring scripts, which count as code, that have been running for 10+years.
Maybe my contributions to curb the ruby binding for ruby? Anyone using it?