Neither, you’re reading it wrong. Think of it as codebases getting more reliable over time as they accumulate fixes and tests. (As opposed to, say, writing code in NodeJS versus C++)

Age of Code does not automatically equal quality of code, ever. Good code is maintained by good developers. A lot of bad code is pushed out by management, and other situations, or just bad devs. This is a can of worms you're talking your way into.

Old code that has been maintained (bugfixed), but not messed with too much (i.e. major rewrites or new features) is almost certain to be better than most other code though?

"Bugfixes" doesn't mean the code actually got better, it just means someone attempted to fix a bug. I've seen plenty of people make code worse and more buggy by trying to fix a bug, and also plenty of old "maintained" code that still has tons of bugs because it started from the wrong foundation and everyone kept bolting on fixes around the bad part.

One of frustrating truths about software is that it can be terrible and riddled with bugs but if you just keep patching enough bugs and use it the same way every time it eventually becomes reliable software ... as long as the user never does anything new and no-one pokes the source with a stick.

I much prefer the alternative where it's written in a manner where you can almost prove it's bug free by comprehensively unit testing the parts.

Listen to yourself. It's like you're denying the concept of improvement.

It's pointlessly argumentative to point out that some code doesn't get better.

Some code does and unlike AI it can be done with clear, precise, incremental changes.

I’ve read parts of macOS’ open source code that surely has been around for a while, maintained and absolute rubbish.

It actually might. Older code running in production is almost automatically regression tested with each new fix. It might not be pretty, but it's definitely more reliable for solving real problems.

The list of bugs tagged regression at work certainly suggests it gets tested... But fixing those regressions...? That's a lot of dev time for things that don't really have time allocated for them.

You're using different words - the top comment only mentioned the reliability of the software, which is only tangentially related to the quality, goodness, or badness of the code used to write it.

Old software is typically more reliable, not because the developers were better or the software engineering targeted a higher reliability metric, but because it's been tested in the real world for years. Even more so if you consider a known bug to be "reliable" behavior: "Sure, it crashes when you enter an apostrophe in the name field, but everyone knows that, there's a sticky note taped to the receptionist's monitor so the new girl doesn't forget."

Maybe the new software has a more comprehensive automated testing framework - maybe it simply has tests, where the old software had none - but regardless of how accurate you make your mock objects, decades of end-to-end testing in the real world is hard to replace.

As an industrial controls engineer, when I walk up to a machine that's 30 years old but isn't working anymore, I'm looking for failed mechanical components. Some switch is worn out, a cable got crushed, a bearing is failing...it's not the code's fault. It's not even the CMOS battery failing and dropping memory this time, because we've had that problem 4 times already, we recognize it and have a procedure to prevent it happening again. The code didn't change spontaneously, it's solved the business problem for decades... Conversely, when I walk up to a newly commissioned machine that's only been on the floor for a month, the problem is probably something that hasn't ever been tried before and was missed in the test procedure.

Yup, I have worked on several legacy codebases, and a pretty common occurence is that a new team member will join and think they may have discovered a bug in the code. Sometimes they are even quite adamant that the code is complete garbage and could never have worked properly. Usually the conversation goes something like: "This code is heavily used in production, and hasn't been touched in 10 years. If it's broken, then why haven't we had any complaints from users?"

And more often than not the issue is a local configuration issue, bad test data, a misunderstanding of what the code is supposed to do, not being aware of some alternate execution path or other pre/post processing that is running, some known issue that we've decided not to fix for some reason, etc. (And of course sometimes we do actually discover a completely new bug, but it's rare).

To be clear, there are certainly code quality issues present that make modifications to the code costly and risky. But the code itself is quite reliable, as most bugs have been found and fixed over the years. And a lot of the messy bits in the code are actually important usability enhancements that get bolted on after the fact in response to real-world user feedback.

Old software is not always more reliable though, which is my point. We can all think of really old still maintained software that is awful and unreliable. Maybe I'm just unlucky and get hired at places riddled with low quality software? I don't know, but I do know nobody I've ever worked with is ever surprised, only the junior developers.

Reality is management is often misaligned with proper software engineering craftsmanship at every org I've worked at except one, and that was because the top director who oversaw all of us was also a developer and he let our team lead direct us whichever way he wanted us to.

I think we all agree that the quality of the code itself goes down over time. I think the point that is being made is that the quality of the final product goes up over time.

E.g. you might fix a bug by adding a hacky workaround in the code; better product, worse code.

The author didn't mean that an older commit date on a file makes code better.

The author is talking about the maturity of a project. Likewise, as AI technologies become more mature we will have more tools to use them in a safer and more reliable way.

I've seen too many old projects that are not by any means better no matter how much they get updates because management define priorities. I'm not alone in saying I've been in a few projects where the backlog is rather large. When your development is driven by marketing people trying to pump up sales, all the "non critical" bugs begin to stack up.

Absolutely. Which is why the author clearly meant "old code" as in mature. Not "old code" as in "created a long time ago".

Sounds more like survivorship bias. All the bad codebases were thrown out and only the good ones lasted a long time.

Basically the Lindy Effect: https://en.wikipedia.org/wiki/Lindy_effect

In my experience actively maintained but not heavily modified applications tend towards stability over time. It don't even matter if they are good or bad codebases -- even a bad code will become less buggy over time if someone is working on bug fixes.

New code is the source of new bugs. Whether that's an entirely new product, a new feature on an existing project, or refactoring.

Survivorship bias is real, but is missing the important piece of the story when it comes to software, which doesn't just survive but is also maintained. Sure you may choose to discard/replace low quality software and keep high quality software in operation, which leads to survivorship bias, but the point here is that you also have a chance to find and fix issues in the one that survived, even if those issues weren't yet apparent in version 0.1. Author is not trying to say that version 0.1 of 30 year old software was of higher quality than version 0.1 of modern software -- they're saying that version 9 of 30 year old software is better than version 0.1 of modern software.

well said, yes this is the point I was (apparently failing) to make

well, yes, exactly. I'm not trying to claim that old code is more reliable just because it was written a long time ago, I'm making the claim that old code is more reliable because of the survivorship bias. If code was first written 20 years ago and is still in production, unchanged, I can be relatively certain there's no stop-the-world bugs in those lines. (this says nothing about how pretty the code is, though).

You mean think of it as opposite to what is written in the remark, and then find it funny?

Yes, I did that.

I’ve always called this “Work Hardening”, as in, the software has been improved over time by real work being done with it.

Ok, but metal that has been hardened is more prone to snapping once it loses its ductility

Perhaps better rephrased as "software that's been running for a (long) while is more reliable than software that only started running recently."

Holy survivorship bias, Batman.

If you think modern software is unreliable, let me introduce you to our friend, Rational Rose.

Agreed.

Or debuggers that would take out the entire OS.

Or a bad driver crashing everything multiple times a week.

Or a misbehaving process not handing control back to the OS.

I grew up in the era of 8 and 16 bit micros and early PCs, they where hilariously less stable than modern machines while doing far less, there wasn’t some halcyon age of near perfect software, it’s always been a case of things been good enough to be good enough but at least operating systems did improve.

Remember BSODs? Used to be a regular occurrence, now they're so infrequent they're gone from windows 11

And the "cooperative multitasking" in old operating systems where one program locking up meant the whole system was locked up

I guess that is because you run it on old hardware. When I've bought my Asus ROG expensive laptop I had bsod almost daily. A year later with all updates I had bsod once in a month on the same device and windows installation.

If you have faulty hardware no amount of software is going to solve your problems (other than software that just completely deactivates said faulty hardware).

The fact you continued to have BSOD issues after a full reinstall is pretty strong evidence you probably had some kind of hardware failure.

But there was no reinstall in my case. Years goes by and further in time there are less and less bsod.

My point is if you are using the same "old" modern hardware, bsod is very rare.

Ah, sorry, I misread your comment. Glad you're getting a better experience with your device over time!

Depends, if you install games with anti-cheat they can often conflict and cause BSODs.

It's why I don't play the new trackmania.

Still get them fairly regularly except now they come with a QR code.

Gone? I had two last year, lets not overstate things.

My anecdata is that my current PC is four years old, with the same OS install, and I can't even recall if I've seen one BSoD.

Daily+ occurrences to two in a year pretty much rounds to zero. Kind of like we said measles were eradicated because there was <X per year cases.

Mostly because Microsoft shut down kernel access, wrote it's own generic drivers for "simple" devices (USBs, printers, sound cards, ...) and made "heavy" drivers submit to their WHQL quality control to be signed to run.

They're definitely not gone.

I remember Linux being remarkable reliable throughout its entire life in spite of being rabidly worked on.

Windows is only stabilizing because it's basically dead. All the activity is in the higher layers, where they are racking their brains on how to enshittify the experience, and extract value out of the remaining users.

As a Windows driver developer: LOL

I grew up in the same era and I recall crashes being less frequent.

There were plenty of other issues, including the fact that you had to adjust the right IRQ and DMA for your Sound Blaster manually, both physically and in each game, or that you needed to "optimize" memory usage, enable XMS or EMS or whatever it was at the time, or that you spent hours looking at the nice defrag/diskopt playing with your files, etc.

More generally, as you hint to, desktop operating systems were crap, but the software on top of it was much more comprehensively debugged. This was presumably a combination of two factors: you couldn't ship patches, so you had a strong incentive to debug it if you wanted to sell it, and software had way fewer features.

Come to think about it, early browsers kept crashing and taking down the entire OS, so maybe I'm looking at it with rosy glasses.

You are looking back with rosy glasses indeed.

Last year I assembled a retro PC (Pentium 2, Riva TNT 2 Ultra, Sound Blaster AWE64 Gold) running Windows 98 to remember my childhood, and it is more stable than what I remembered, but still way worse than modern systems. There are plenty of games that will refuse to work for whatever reason, or that will crash the whole OS, specially when existing, and require a hard reboot.

Oh and at least in the '90s you could already ship patches, we used to get them with the floppies and later CDs provided by magazines.

FWIW, I was speaking of the 80s.

It truly depends on the quality of the software you were using at the time. Maybe the software you used didn't result in many issues. I know a lot of the games I played as a kid on my family's or friend's Win95 machines resulted in system lockups or blue screens practically every time we used them.

As I mess around with these old machines for fun in my free time, I encounter these kinds of crashes pretty dang often. Its hard to tell if its just the old hardware is broken in odd ways or not so I can't fully say its the old software, but things are definitely pretty unreliable on old desktop Windows running old desktop Windows apps.

As an OS/2 and Linux users, I mostly missed out on Win95 fun.

But I was thinking of the (not particularly) golden days of MS-DOS/DR-DOS/Amiga/Atari applications.

Or just http without the s. We take it for granted now, but not even that long ago http was the standard.

But at the time that software was "new" and unreliable.

ah yes, one person understands the point I was trying to make (:

I know very little about Rational Rose, other than it always sounded like the stage name of a Vulcan stripper.

You know, I had spent a good amount of years not having even a single thought about rational rose, and now that’s all over.

I do apologize. I couldn't bear this burden alone.

How much of that do you think would be attributable to IBM or Rational Software?

It could definitely be worse. I have the privilege of using it weekly :(

What? How? I thought we stamped it out in the Purge of 2007.

Some things are forged in hell and refuse to die.

Ah, yes, the Oracle product model.

Rational Rhapsody called and wants the crown back

At least that project was wise enough to use Lisp for storing its project files.

I think old in this sense is "released" rather than "beta" - it takes time to make any software reliable. Many of the examples here further prove that young software is unreliable.

Remember when debuggers were young?

Remember when OSes were young?

Remember when multi-tasking CPUs were young?

Etc...

Yes this is what I was trying to say. Code that's been in production for 20 years has less bugs than code that's been around for 20 minutes

You misunderstand. They are explicitly referring to the survivors that have been iterated on.

They're NOT saying all software in the past was better.

correct.

I was maybe a little unclear with the phrasing, I meant to say "software that's been around for 20 years is more reliable than software that's been around for 2 months"