Live data from Hacker News

The great software quality collapse or, how we normalized catastrophe

techtrenches.substack.com

101–110 of 260 posts

Re: The great software quality collapse or, how we normalized catastrophe

#101

I find it ironic that an article that rails against AI usage contains a sentence like this. >When you need $364 billion in hardware to run software that should work on existing machines, you're not scaling—you're compensating for fundamental engineering failures. IYKYK.

It all reads like hallucinated slop from top to bottom "I've been tracking software quality metrics for three years" and then doesn't show any of the receipts, and simply lists anecdotal issues. I don't trust a single fact from this article. My own anecdote: barely capable developers churning out webapps built on PHP and a poor understanding of Wordpress and jQuery were the norm in 2005. There's been an industry tren…

"barely capable developers churning out webapps built on PHP and a poor understanding of Wordpress and jQuery were the norm in 2005"

It was the norm in 1998 also, based on the "dotcom" era code I saw.

Re: The great software quality collapse or, how we normalized catastrophe

#102
post #73
post #62

Earlier quoted context omitted.

If you haven't noticed a dramatic decline in average software quality, you're not paying attention or willfully ignoring it. The article is right. This is partly related to the explosion of new developers entering the industry, coupled with the classic "move fast and break things" mentality, and further exacerbated by the current "AI" wave. Junior developers don't have a clear path at becoming senior developers anymo…

Is this measureable? Like code readability scores on the GitHub corpus over time?

The complaint is not about the readability of the code but of the quality and cost effectiveness of the deployed software.

Re: The great software quality collapse or, how we normalized catastrophe

#103
post #28

Unrelated but my current AI text flag is the use of "It's not X. It's Y." It's become so repetitive recently. Examples from this post alone: 1. "This isn't about AI. The quality crisis started years before ChatGPT existed." 2. "The degradation isn't gradual—it's exponential." 3. "These aren't feature requirements. They're memory leaks that nobody bothered to fix." 4. "This wasn't sophisticated. This was Computer Scie…

I've always talked like this, I'm sure others do too.

Re: The great software quality collapse or, how we normalized catastrophe

#104
There are only two valid business answers:

1. hiring/firing frequency.

2. Elimination of training.

Everything else is secondary and nothing else comes close.

This is true enough that competing pressure almost universally comes from law suits and regulatory compliance. Generally, even competition is not enough to steer the ship in a different direction. It is not about making money. It is only about avoiding loss of money from penalties. Money is made from licensing and contracts completely irrespective of the development and/or maintenance costs. The costs of writing software is challenging to estimate and so it is either measured in release duration only or discarded outright.

Implicit to hiring/firing frequency is the cost of training. Elimination of training requires that training occur from somewhere, anywhere, external to the current employer. When that mindset becomes universal then nobody performs or validates training in any form. The consequence is to assume everybody is well trained based exclusively upon their employment history, which is nonsense if no employers provide training.

So software quality will continue to degrade as the quality of candidates writing that software continues to degrade. It is interesting to watch through the lens of Dunning-Kruger stupidity, because developers commonly believe this nonsense literally. Its why so many developers call themselves engineers and yet can't read a ruler, or any other measuring implement.

Just about everybody anticipates AI will greatly accelerate this sprint to the bottom.

Re: The great software quality collapse or, how we normalized catastrophe

#105
Building software extremely expensive and slow. All of us are balancing quality and speed.

The ultimate goal of building software isnt quality, its aggregate customer value delivered over time, and poor quality undermines customer value. We all have limited resources and are doing our best.

The author can go maximize quality while delivering more slowly/expensively. End users can choose which products they want. Something tells me users may choose products that have more defects but deliver more customer value.

Re: The great software quality collapse or, how we normalized catastrophe

#106
It reeks a bit of tech self importance. From an overall business context, you balance time/effort vs short/long term reward and design or fix things when you need to.

There are many dials to manipulate in a business to make it more efficient. And not all businesses are tech startups. Software, fortunately or unfortunately, has a lot of room to be inefficient due to cheap hardware as long as it gets the job done in a lot of industries.

I have a technical background as a data scientist and developer. If I look back 5-10 years ago, I can definitely recognize my bias towards over-engineering and premature perfectionism. Identifying that sweet spot between over-designing and unplanned failure is key.

Re: The great software quality collapse or, how we normalized catastrophe

#107
post #59

I wouldn’t blame the “ever expanding” abstractions as the root cause behind lower quality. Adding layers of abstraction is how we make ever more complex software. It’s misleading to think that just because the main human interface idioms have remained similar (mouse, pointer, windows, task bars, etc), there hasn’t been an astronomical increase in depth and complexity of what one can do on one’s system. And it’s not a…

[deleted]

Re: The great software quality collapse or, how we normalized catastrophe

#108

Earlier quoted context omitted.

I would have disagreed with you in the past by saying, "until it breaks something critical and you loose customers and business", but then again people just moved on from the Crowdstrike incident like business as usual.If something like that which grounded critical service globally and had an estimated 10 Billion Dollar economic impact doesn't change mindsets,I don't know what will.

That's because no one died. All the safety critical industries are already heavily regulated. E.g. check out for example standards like DO-178C (for software in airborne systems), where you even have to _prove_ correctness of every tool and dependency you use, on top of accountability and traceability of every single line of code in your own product.

And memory leaks (one of the main gripes of TFA) aren't even a thing because you cannot use malloc in this sort of code.

Re: The great software quality collapse or, how we normalized catastrophe

#109

Earlier quoted context omitted.

One could easily imagine the analogy, e. g. the amount of commercial software (in critical infrastructure) that "leaked kBytes and MBytes of memory", as well as embarassing "Computer Science 101 error handling" fuck-ups of the day with billion dollar consequences, but I believe you got it surrounded...

Ariane 5? Therac-25? Anyone? Bueller? Bueller?

If you Ferris-wheel some good hard info into an amusing article, I'll read it. Promise.

Re: The great software quality collapse or, how we normalized catastrophe

#110

I’ve read some versions of this post dozens of times over the years. At first I would nod along, sympathetic but now I realise that we shouldn’t chase some platonic ideal of perfect software. It has to exist in the real world and there will always be trade offs. In the end, most software exists to make businesses money.

How much money was made by a worse calculator in the 'real world'?
Post reply on HN