6 ms·

> AIs will get more reliable over time, like old software is more reliable than new software. :) Was that a humam Freudian slip, or artificial one? Yes, old

> AIs will get more reliable over time, like old software is more reliable than new software. :) Was that a humam Freudian slip, or artificial one? Yes, old software is often more reliable than new.

joomla199 1y ago
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++)
- giancarlostoro 1y ago
  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.
  - 1313ed01 1y ago
    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?
    - eptcyka 1y ago
      I’ve read parts of macOS’ open source code that surely has been around for a while, maintained and absolute rubbish.
    - DSMan195276 1y ago
      "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.
      - gridspy 1y ago
        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.
      - deleted 1y ago
        [deleted]
  - prasadjoglekar 1y ago
    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.
    - shakna 1y ago
      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.
  - LeifCarrotson 1y ago
    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.
    - freetime2 1y ago
      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.
  - hatthew 1y ago
    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.
  - kube-system 1y ago
    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.
    - giancarlostoro 1y ago
      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.
      - kube-system 1y ago
        Absolutely. Which is why the author clearly meant "old code" as in mature. Not "old code" as in "created a long time ago".
- izzydata 1y ago
  Sounds more like survivorship bias. All the bad codebases were thrown out and only the good ones lasted a long time.
  - wsc981 1y ago
    Basically the Lindy Effect: https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
  - wvenable 1y ago
    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.
  - topaz0 1y ago
    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.
    - beyarkay 1y ago
      well said, yes this is the point I was (apparently failing) to make
  - beyarkay 1y ago
    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).
- kazinator 1y ago
  You mean think of it as opposite to what is written in the remark, and then find it funny? Yes, I did that.
- james_marks 1y ago
  I’ve always called this “Work Hardening”, as in, the software has been improved over time by real work being done with it.
  - jazzyjackson 1y ago
    Ok, but metal that has been hardened is more prone to snapping once it loses its ductility
glitchc 1y ago
Perhaps better rephrased as "software that's been running for a (long) while is more reliable than software that only started running recently."
kstrauser 1y ago
Holy survivorship bias, Batman. If you think modern software is unreliable, let me introduce you to our friend, Rational Rose.
- kazinator 1y ago
  At least that project was wise enough to use Lisp for storing its project files.
- noir_lord 1y ago
  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.
  - malfist 1y ago
    Remember BSODs? Used to be a regular occurrence, now they're so infrequent they're gone from windows 11
    - kazinator 1y ago
      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.
    - wlesieutre 1y ago
      And the "cooperative multitasking" in old operating systems where one program locking up meant the whole system was locked up
    - krior 1y ago
beyarkay 1y ago
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"

> AIs will get more reliable over time, like old software is more reliable than new software. :) Was that a humam Freudian slip, or artificial one? Yes, old software is often more reliable than new.

joomla199 1y ago

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++)

giancarlostoro 1y ago
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.
- 1313ed01 1y ago
  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?
  - eptcyka 1y ago
    I’ve read parts of macOS’ open source code that surely has been around for a while, maintained and absolute rubbish.
  - DSMan195276 1y ago
    "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.
    - gridspy 1y ago
      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.
    - deleted 1y ago
      [deleted]
- prasadjoglekar 1y ago
  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.
  - shakna 1y ago
    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.
- LeifCarrotson 1y ago
  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.
  - freetime2 1y ago
    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.
- hatthew 1y ago
  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.
- kube-system 1y ago
  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.
  - giancarlostoro 1y ago
    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.
    - kube-system 1y ago
      Absolutely. Which is why the author clearly meant "old code" as in mature. Not "old code" as in "created a long time ago".
izzydata 1y ago
Sounds more like survivorship bias. All the bad codebases were thrown out and only the good ones lasted a long time.
- wsc981 1y ago
  Basically the Lindy Effect: https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
- wvenable 1y ago
  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.
- topaz0 1y ago
  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.
  - beyarkay 1y ago
    well said, yes this is the point I was (apparently failing) to make
- beyarkay 1y ago
  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).
kazinator 1y ago
You mean think of it as opposite to what is written in the remark, and then find it funny? Yes, I did that.
james_marks 1y ago
I’ve always called this “Work Hardening”, as in, the software has been improved over time by real work being done with it.
- jazzyjackson 1y ago
  Ok, but metal that has been hardened is more prone to snapping once it loses its ductility

glitchc 1y ago

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

kstrauser 1y ago

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

kazinator 1y ago
At least that project was wise enough to use Lisp for storing its project files.
noir_lord 1y ago
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.
- malfist 1y ago
  Remember BSODs? Used to be a regular occurrence, now they're so infrequent they're gone from windows 11
  - kazinator 1y ago
    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.
  - wlesieutre 1y ago
    And the "cooperative multitasking" in old operating systems where one program locking up meant the whole system was locked up
  - krior 1y ago

beyarkay 1y ago

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"