Digest

Software used to be horrible. HN listed which bugs died, and what killed them

A 329-comment HN thread argued whether software got worse. We mapped each bug class it named to the mechanism that ended it, and asked what holds the floor now.

Published Updated 4 min read

Jake Voytko's "Software may be getting worse, but it used to be horrible" drew 321 points and 329 comments on Hacker News this week. He has used computers since 1990, and his case is a museum tour: the Blue Screen of Death, apps without autosave, drivers on floppy disks. The thread split on whether he is right. Our read: the more useful thing in it is a list nobody set out to write. When commenters explained why an old bug class went away, the answer was almost never "people got more careful". It was a mechanism. The new bug classes they named have no mechanism yet.

The one claim worth keeping

Voytko's sharpest line is not about crashes. It is about release: "companies only got one chance to ship their software." The disc was pressed and mailed, "so there was some quality floor that you couldn't slip below."

He also states the arithmetic for today: "if you increase your code production by 10x but you don't reduce your error rate by a factor of 10, then your production app is buggier than it used to be." Put the two together and you get the thread's real question. The floor came from a ship date you could not take back. Continuous delivery removed the date. What holds the floor now?

Which bugs died, and what killed them

We went through the thread for every comment that named a specific bug class and said why it got better or worse. This table is the result.

Bug classThenWhat changed it, per the thread
OS crashes from apps"dangerous memory model/lack of memory isolation" in Windows up to MEMemory isolation in the OS (Someone1234)
Kernel instability from third-party code"software was monkey-patching the kernel", antivirus includedKernel Patch Protection, KPP (Someone1234)
UI out of sync with data"UIs were constantly out of sync with the underlying data"Reactive frameworks (gf000)
Install and dependency breakage"30+ step tutorials with manual patching""DLL hell is a thing of the past" (TrackerFF)
Driver crashesAn HP printer driver unloaded its own floating-point emulationOne admin found it, once (mikewarot)

Four of the five rows end with something built into the platform. Nobody had to remember to avoid the bug; the platform made it hard or impossible to write. The fifth is the old way: one person traced one driver, and "we never had problems again, for over a decade".

Games got the same treatment. CM30 pointed at titles shipped close to broken, including SQIJ!, whose player "couldn't move due to the game only looking for lower case inputs while leaving the caps lock on". Their verdict was that "the baseline level of competence arguably seems to be getting higher". That fits the table: the baseline rose where something enforced it.

What the thread says is new

The same commenters were specific about what got worse, and none of it is on Voytko's list.

Latency. xmddmx searched the comments for the word and found none: "Latency is one metric by which computing has gotten noticeably worse over the years." Clicks that take "from several hundred to several thousand milliseconds", often with "stale data" showing and "no visual indication a process is underway".

Untested paths that only run when things go wrong. renegade-otter had to reinstall Windows because a new recovery feature looped "every 30 minutes" and nobody had tested it with USB input devices. "Even in the worst days of Windows, this would have been a huge deal."

Regressions shaped differently. ang_cire's framing is the most precise in the thread: software "is not a linear track, so regression is not going to result in the same 'bads' that existed back then, it's resulting in new ones."

The takeaway

Look at the shape of the new list. Slow feedback after a click, a recovery path nobody exercised, a regression that looks nothing like the bug you tested for last time. None of these is stopped by memory isolation or a type system. Each one is about behaviour: what the app did after a real action, on a path that runs rarely.

That is where the missing floor belongs. The old floor was a date. The replacement has to be a check that runs on every change and fails when a real journey stops working: the recovery flow, the slow click, the checkout. That is a mechanism, like the four rows above, and it does not depend on anyone having a careful sprint.

If the 10x arithmetic is right, vigilance cannot keep up by definition. The bug classes that died show what can.

Caveats. This is one thread, read by us, and the table only covers comments that named a cause. Several commenters argued that many old failures were hardware, not software, which the table does not try to settle.

Sources

  1. 01bitlog.com: Software may be getting worse, but it used to be horriblewww.bitlog.com
  2. 02Hacker News: Software may be getting worse, but it used to be horriblenews.ycombinator.com
  3. 03Hacker News: Someone1234 on what caused BSODsnews.ycombinator.com
  4. 04Hacker News: gf000 on UI and data syncnews.ycombinator.com
  5. 05Hacker News: TrackerFF on DLL hellnews.ycombinator.com
  6. 06Hacker News: xmddmx on latencynews.ycombinator.com
  7. 07Hacker News: renegade-otter on an untested recovery pathnews.ycombinator.com
  8. 08Hacker News: ang_cire on new regressionsnews.ycombinator.com
  9. 09Hacker News: CM30 on gamesnews.ycombinator.com
  10. 10Hacker News: mikewarot on a printer drivernews.ycombinator.com
Reticleverdict

// The agent clicked "Pay". Did the right things actually happen?

{verified: "no"failureReason: "POST /api/order returned 500, expected 200"source: "src/checkout/PayButton.tsx:42"}

Example from the README

Your agent says it works. Reticle checks the network, state and console inside your running app, and names the line to fix.

85 of 88 seeded bugs caught in the public benchmark