Good Old Code

Earlier today I was thinking about how little of the software I've written since 1994 is still in use today. The oldest application that I know to be running was written back in 2006 while the oldest bits of code that I personally use were written somewhere around 20001. Nothing that I wrote in the 90s exists today and, even if it did, nobody would want to use it. Heck, very little of the code that anybody wrote in the 90s continues to exist today outside of some very legacy systems used within governments, militaries, nuclear power plants, and banks2. There's a good reason for this, too: software in the 90s was rough.

When I think about software from 25 years ago, Windows95 springs to mind. The promise of Microsoft's ambitious operating environment was attractive, but the implementation was incomplete. Applications would crash all the time3 and, because everything had to be "multimedia", we would need to have large binders of CDs next to the computer for all the resources that couldn't fit on the internal hard drive4. There is little chance that anybody would willingly choose to use Windows95 and a myriad of compatible software from the same time period today.

Or so I initially thought. Then I remembered how my friends and I would use computers when there weren't any adults around: Doom and Doom II.

Operating systems, operating environments, and productivity software from 25 years ago are probably best forgotten. Games, however, can have a much longer lifespan. I can actually say that I've run Doom II on a 386, a 486, a Pentium, a Pentium II, a Pentium III, a Pentium 4, an AMD Athlon XP, a Core2Duo, a 4th Generation Core i7, a 5th Generation Core i5, and a 9th Generation Core i75. 35 years of computer development for a game that was released in the autumn of 1994.

Silly as it might seem, I find it fascinating that of all the software that was written before Y2K, Doom and other games from the same era are likely the only examples of applications made for general consumption that have seen more than a quarter century of use.

Is there any chance that I might write an application that people enjoy using for a quarter century or more without updates? Probably not. Modern software is often more dependent on its operating system than applications written in the past. That said, who knows what the future might have in store. A well-written, self-contained tool for a Linux-based system might enjoy a longer operational life than something written for Windows or macOS.


  1. An example would be the NoNull() function found in 10C's /lib/functions.php. It was rewritten for PHP a decade ago to replicate a very useful task that I had picked up from an earlier time while developing VB6 applications that would read from a SQL Server database. NoNull() — and it's integer variant nullInt() — are "old" pieces of code that have remained largely unchanged in 20 years despite being re-written in several programming languages.

  2. There are bound to be a good bit of code within Unix that hasn't been updated in quite some time, too. Anything that isn't dependent on dates or very large numbers would have avoided Y2K and 64-bit updates.

  3. I switched from WordPerfect to Word in the late 90s simply because WordPerfect would literally crash after every page. I would save my documents after every paragraph. Word95 didn't have this issue and, if that wasn't reason enough to switch, Microsoft's word processor was faster and easier to understand. Believe it or not, it had fewer buttons than any of the competition.

  4. Remember when a single CD could hold almost twice as much data as a hard drive? Those were rough days.

  5. It was after the Athlon XP that I stopped upgrading my systems every 6 ~ 8 months, hence the gaps in processor generations. And, yes … I've played Doom II on a 2019-era MacBook Pro.