4 ms·

It's crazy to think about, but many people who use and build software today, including HN readers/commenters, are young enough to have only been exposed to the

• dfghbbjiiugb 4y ago
  Your broad point is obviously correct (most outages are caused by code or config changes) but there are still classes of failures that can happen without any real changes, like various performance degradations (maybe your table grows too large) or occasional catastrophic failures from things like disk space or id overflow or something. There's also the stability of third party systems: forced deprecations, security EOL, etc. The cert expiration stuff people have been mentioning is in this category too. I wouldn't be surprised if something does slip through the cracks at Twitter in the next 4 or 6mo.
  • whizzter 4y ago
    A few of us remembers the time Slashdots 24-bit comment table ID keys overflowed, was a fun couple of days.
  • marstall 4y ago
    also: regulatory changes. if you can't function within the law, that's tantamount to a critical bug.
• mgkimsal 4y ago
  The other side of that is browsers. Even if you don’t change your code, the platform people are running your code in changes, automatically in many cases. New JS or CSS behavior in next safari or chrome? You need to patch/push to accommodate running environments that are outside your control.
  • christophilus 4y ago
    The old space jam site worked for ages, and would still work if they hadn’t taken it down. The web is pretty good about keeping backwards compatibility.
    • efreak 4y ago
      Except the original hamster dance, which doesn't display correctly
    • veqq 4y ago
  • vasergen 4y ago
    JS in fact has very good backwards compatability, this is by the way the reason why "old stuff" are not removed and are still in the language.
  • bdcravens 4y ago
    Sounds like a good argument for minimal Javascript.
• shapefrog 4y ago
  > The cloud/SaaS approach You dont have to push constant updates for a cloud / SaaS product - many chose to - but ultimately you dont have to. A year of 'no new features' should be something customers and vendor alike benefit from.
  • awithrow 4y ago
    Depending on your stack, security patching can constitute a non-trivial amount of changes as well.
• Lutger 4y ago
  Absolutely. I remember we build a unimaginably brittle application many years ago, I think it was running on Windows XP and glued together a complex system with COM calls into this single page webapp even before react was a thing. It was build on a very small budget, serving the core business of a very tiny company. Like maybe 8 years later I found out it was still humming along happily, without really even a sysadmin attending to it, on a single workstation using consumer hardware, servicing the company that had grown tenfold in size. It blew my mind it still just worked all these years.
• mrazomor 4y ago
  The ecosystem changed since then. Now updates of your binary's environment are more frequent, and often enforced. How often did you update or patch your Windows 98 or NT? Today, it's false to assume that fire and forget releasing will work even for standalone Windows binaries.
• Tade0 4y ago
  I remember how it was over a decade ago and one hallmark of such systems was that they were easy to exploit. My friend in college would just go into Wordpress admin panels and the like by using common exploits because nobody updated PHP on their VPSes back then. As someone who spent most of their career to date as a front-end developer I learned that as long as they have the budget, stakeholders are insatiable. It's just that ten years ago most of their ideas were either technically not feasible or very expensive. Nowadays browsers are much more capable, so the pressure to produce more features is much greater. To our own peril, we can do much more now.