Is software getting worse? 46 HN comments, two numbers

Jake Voytko's post on October 27 argued that software may be getting worse but used to be horrible, and the Hacker News thread ran to about 175 comments. We read and sorted all 46 top-level ones. Two cited a number. Our view: the argument cannot be settled because almost nobody measures the thing it is about, and Voytko's own first paragraph names the metric.

What the post argues

Voytko starts with arithmetic: "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." Then he spends the rest of the post on memory: blue screens, applications with no autosave, and device drivers that shipped on a floppy and could not be fixed.

He also names the one thing the old era had going for it: "companies only got one chance to ship their software." A release went onto a floppy disk or a CD and into a box, so "there was some quality floor that you couldn't slip below." Continuous delivery removed that floor. A bad build can now be fixed tomorrow, which is a real benefit, and it also means nothing forces anyone to check today's build before it reaches users.

His most interesting detail is a measurement. On the Google Docs team in 2010, they instrumented Ctrl+S, which did nothing because Docs autosaves. It was "in the top 5 non-editing user actions". Years of lost work had trained a reflex.

How the thread split

We sorted each top-level comment by the position it takes. This is one reader's classification, so treat the edges as soft.

Two more counts stood out. Seven comments blamed AI-assisted coding for a decline, and three credited it with an improvement. And only two of the 46 offered a number as evidence.

Three arguments worth keeping

Reliability went up, feel went down. quacked put it plainly: software's "reliability has increased a thousandfold in my lifetime, but its actual controllability/feel/UI-UX has been rapidly declining for about a decade." xmddmx added a measurable version: he searched the post for "latency", found nothing, and described delays "from several hundred to several thousand milliseconds" after a click. TrackerFF took the other side: "DLL hell is a thing of the past."

Small parts improved, systems did not. Pannoniae argued that software "used to be much worse on the micro-level but better on the macro-level i.e. architecture". Libraries and better languages fixed the small things, while large systems now suffer "a death of thousand cuts".

The network made it less deterministic. iamcalledrob wrote that "90s software ran mostly offline. It was simpler and more deterministic." A UI that waits on a server round trip has failure modes a disk-bound program never had.

The two numbers

One of the two most-replied comments came from brookst, who asked: "Where are the metrics of degradation?" Then he offered one. A pre-AI project of his had a test-to-code ratio of "0.15:1", and the projects he works on now are "around 1.3:1". That is one developer's codebase, not an industry trend, but it is a number someone can check.

The counter-example came from NicoJuicy, whose accountant built a web app with an AI assistant and "has no dev and no test environment". Both stories are about the same tools. What differs is whether anyone checked the output.

The thread also had the opposite view, stated without hedging. reenorap wrote that they accept AI-written code and "don't even code review it as a matter of principle", on the grounds that "if there are any bugs then just ask the AI to fix it." That works only if someone notices the bug first. Without a count of what escapes, "just fix it" means the users find the bugs.

The takeaway

Voytko's sentence is a formula, and it is the one most teams cannot fill in. If code volume goes up tenfold, the defect rate per change has to fall tenfold just to stay level. You can only know whether it did if you count it.

Two numbers are enough to start:

1. Changes merged per week. Most teams have this already.
2. Defects found after merge, per hundred changes. Bugs from production, support tickets traced to a change, rollbacks, and hotfixes.

Track the second one monthly. If your merge rate doubled this year and that number did not halve, your software is getting worse, whatever it felt like in 1998. If it fell, you have the evidence this thread was missing.