Ask HN: Why is software quality collapsing?

[2] Vanity of vanities, says the Preacher, vanity of vanities! All is vanity. [3] What does man gain by all the toil at which he toils under the sun? [4] A generation goes, and a generation comes, but the earth remains forever. [5] The sun rises, and the sun goes down, and hastens to the place where it rises.

[11] For I know full well the plans I have for you, plans for your welfare and not for your misfortune, plans that will offer you a future filled with hope. [12] When you call out to me and come forth and pray to me, I will listen to you.

I think there’s often a misalignment of incentives when annual perf reviews are judged on feature work delivered not quality. Engineers who spend any time polishing or finding and fixing bugs wind up rated mid, while folks who quickly crank out mediocre or bad code that does something new are on a fast track for promotion. This creates a current in the whole org where PMs, engineers, managers, etc., are all focused on new things all the time. Any quality work has to accompany a new feature proposal for traction, and the quality items in that project will never get cross functional support like the new feature work does.

This resource allocation strategy seems rational though. We could consume all available resources endlessly polishing things and never get anything new shipped.

Honestly it seems like the another typical example of the “cost center” vs “revenue center” problem. How much should we spend on quality? It’s hard to tell up front. You don’t want to spend any more than the minimum to prevent whatever negative outcomes you think poor quality can cause. Is there any actual $ increase from building higher quality software than “acceptable”?

razoorka · 3 months ago

I would prefer to pay 20% more for product which works perfectly, than for product which almost works. But no one asked me.

OutOfHere · 3 months ago

You shouldn't, because that 20% more will not go to the engineers; it will go to parasitic management. Money is better if paid for services than for software. I would find well-maintained open source software instead, perhaps contribute to one, or put in the effort to develop one.

godelski · 3 months ago

  > I would prefer to pay 20% more

That's the problem with lemon markets though. They are a feedback loop and usually dependent on asymmetric information.

As a simple version think about it this way: if a customer can't tell the difference in quality at time of purchase then the only signal they have is price.

I think even here on HN if we're being honest with ourselves it's hard to tell quality prior to purchase. Let alone the average nontechnical person. It's crazy hard to evaluate software even hands on. How much effort you need you put in these days. The difficulty of differentiating sponsored "reviews" from legitimate ones. Even all the fake reviews or how Amazon allows changing a product and inheriting the reviews of the old product.

No one asks you because all the sellers rely too heavily on their metrics. It's not just AI people treat like black boxes, it's algorithms and metrics in general. But you can't use any of that effectively without context.

At engineers I think we should be a bit more grumpy. Our job is to find problems and fix them. Be grumpy to find them. Don't let the little things slip because even though a papercut isn't a big deal, a thousand is. Go in and fix bugs without being asked to. Push back against managers who don't understand. You're the technical expert, not them (even if they were once an engineer, those skills atrophy and you get disconnected from a system when you aren't actively working on it). Don't let them make you make arguments about some made up monetary value for a feature or a fix. It's managements job to worry about money and our job to worry about the product. There needs to be a healthy adversarial process here. When push comes to shove, we should prioritize the product over the profit while they should do the opposite. This contention is a feature, not a bug. Because if we always prioritize profits, well, that's a race to the bottom. It kills innovation. It asks "what's the shittiest cheapest thing we can sell but people will still buy". It enables selling hype rather than selling products. So please, be a grumpy engineer. It's in the best interest of the company. Maybe not for the quarter, but it is for the year and the decade. (You don't need to be an asshole or even fight with your boss. Simply raising concerns about foreseeable bugs can be a great place to start. Filling bug reports for errors you find too! Or bugs your friends and family find. Or even help draft them with people like on HN that raise concerns about a product your company works on. Doesn't need to be your specific team, but file the bug report for someone who can't)

And as the techies, we should hold high standards. Others rely on us for recommendations. We need to distill the nuances and communicate better with our nontechnical friends and family.

These won't solve everything but I believe they are actionable, do not require large asks, and can push some progress. Better something than nothing, otherwise there will be no quality boots to buy

https://en.wikipedia.org/wiki/Boots_theory

godelski · 3 months ago

This just makes it sound like software engineering hasn't matured yet to realize we're building real world systems. It's still a pretty new field, comparatively, but big companies can't run like startups. They should have groups in them that look like that, but not for most groups

My view is fairly simple - demand for technology is always increasing at a rate which far outstrips supply of _good_ engineers (by a significant factor). The lure of a well paid career tempts many to the world of software engineering even if they're not very good at it.

Look at the construction industry. Many buildings on this planet were built hundreds, sometimes a thousand or more years ago. They still stand today as the quality of their build quality was excellent.

A house built today of cheap materials (i.e poor quality software engineers) as quickly as possible (i.e urgent business timelines) will fall apart in 30 years while older properties will continue to stand tall long after the "modern" house has crumbled.

These days software is often about being first to market with quality (and cough security) being a distant second priority.

However occasionally software does emerge as high quality and becomes a foundation for further software. Take Linux, FreeBSD and curl as examples of this. Their quality control is very high priority and time has proven this to be beneficial - for every user.

razoorka · 2 months ago

Completely agree, software’s “materials” haven’t improved, only the scaffolding around them.

We’ve industrialized the process without industrializing the discipline. The result is mass-produced code built on shaky abstractions, fast to assemble, and faster to decay.

Linux and curl weren’t built on sprints or OKRs. They were built on ownership, long time horizons, and the idea that stability is innovation when everyone else is optimizing for speed.

Desafinado · 2 months ago

This. I was waiting to find this post. In addition, there's the reality that it takes a reasonably long tenure to even know what quality looks like. And some engineers lack the skill to get there at all.

AnimalMuppet · 3 months ago

> Look at the construction industry. Many buildings on this planet were built hundreds, sometimes a thousand or more years ago. They still stand today as the quality of their build quality was excellent.

True. And yet, far more buildings built then are not standing. We just don't notice them, because they aren't still here for us to notice.

So don't think that things were built better then. A few were; most weren't.

akkartik · 3 months ago

Human beings are ephemeral. They're born, they die.

Everything human beings create is ephemeral. That restaurant you love will gradually drop standards and decay. That inspiring startup will take new sources of funding and chase new customers and leave you behind, on its own trajectory of eventual oblivion.

When I frame things this way, I conclude that it's not that "software quality" is collapsing, but the quality of specific programs and companies. Success breeds failure. Apple is almost 50 years old. Seems fair to stipulate that some entropy has entered it. Pressure is increasing for some creative destruction. Whose job is it to figure out what should replace your Apple Calculator or Spotify? I'll put it to you that it's your job, along with everyone else's. If a program doesn't work, go find a better program. Create one. Share what works better. Vote with your attention and your dollars and your actual votes for more accountability for big companies. And expect every team, org, company, country to decay in its own time.

Shameless plug: https://akkartik.name/freewheeling-apps

willswire · 3 months ago

Ecclesiastes 1:2-5

hu3 · 2 months ago

Jeremiah 29:11-12

abnercoimbre · 3 months ago

Agreed, but If I can add one more angle: creative destruction is strangled when engineers are glued to the Internet about “how software should be built.”

I've published a blog post urging [0] top programmers to quit for‑profit social media and rebuild better norms away from that noise.

[0] https://abner.page/post/exit-the-feed/

softwaredoug · 3 months ago

To add to this, many of the things we consider "high quality" are labors of love of 2 people. Many things we consider low quality are built by massive organizations and hundreds of developers each trying to ship one feature, get promoted, or find another job.

iExploder · 2 months ago

The more elaborate your design doc for printing hello world is, the higher the chances for L+1

mckn1ght · 3 months ago

My hot take is that quality is inversely proportional to income. The more someone is paying for something, the more bloodsucking mercenaries are attracted to it that have less consideration for the quality of the output than for their own enrichment. (A corollary to this is that the more a job pays the more it will suck: the only way they can get people to come help and keep them there is to offer high compensation).

Look at trappist brewers. Long tradition of consistent quality. You just have to devote your life to the ascetic pursuit of monkhood. It attracts a completely different kind of person.

It's certainly a provocative thought. But I think it's too blunt. In our commercial world sometimes the cheaper thing works better and sometimes the more expensive thing works better. So the lesson I take away is that price is not a great signal in the absence of other context. Trappist brewers have some other cultural norms going for them, and the focus should be on those norms rather than price. The people attracted to it aren't thinking much about the money. If you value them, why would you?

Dead Comment

cgearhart · 3 months ago

al_borland · 3 months ago

Where I’m at, needless complexity is forced upon us. At the same time, we are constantly pushed to deliver new capabilities on timelines that are dictated to us, devoid of any grounding in reality. There is no room to even have the conversation about proper design or solving the right problems. It’s all about hitting arbitrary dates with “features” no one really cares about, while ignoring the foundation it all has to sit on.

The more loudly someone speaks up, the faster they are shown the door. As a result, most people keep their head down, pick their battles carefully, and try to keep their head above water so they can pay the rent.

I wouldn't work at a place that doesn't value my perspective either. The problem is that most engineers realize this 6-12 months in, after they're already invested, and leaving means starting over. This is why "keep your head down to pay rent" becomes the default. The system is designed to make speaking up too expensive.

irvingprime · 3 months ago

You are in a completely normal dev shop. What's happened is that the start up mentality of "ship something - anything, and ship it NOW" has infected everything. Maybe over time you can make it better. But educating management can be a slow and frustrating process. Good luck!

Someone · 2 months ago

> I've been tracking software quality metrics for 3 years

I don’t think you can draw conclusions from that short a period.

As a counterpoint: in the ‘80s and early ‘90s, my brain was almost hardwired to hit the hotkey for “Save” every few seconds while working, even though that could mean applications became unresponsive for seconds, because I didn’t trust the application to not crash while idle.

Yes, part of that is because applications nowadays rarely run out of memory, and likely don’t have code that tries to keep things running in low-memory conditions, but that’s not all of it. A significant part was that applications were buggy. (Indirect) evidence for that is that they also were riddled with security holes.

PaulHoule · 3 months ago

Shoulda posted your link as a link instead of hiding it in text where we can’t click on it. If your blog post doesn’t stand on its own without an explanation you should rewrite it.

Thank you for your advice, but I’m new here and do not know how the things works here yet. And probably I’m not allowed to post links yet, because of new account

craftkiller · 3 months ago

Ah welcome to HN. This particular etiquette is oddly not covered in the guidelines but instead in the FAQ:

> How do I make a link in a text submission?

> You can't. This is to prevent people from submitting a link with their comments in a privileged position at the top of the page. If you want to submit a link with comments, just submit the link, then add a regular comment.

https://news.ycombinator.com/newsfaq.html

lapcat · 3 months ago

"Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity." https://news.ycombinator.com/newsguidelines.html

Deleted Comment

comprev · 3 months ago

jf22 · 3 months ago

I'd challenge your assumption that quality is collapsing.

I remember the good old days where nobody unit tested, there were no linters or any focus on quality tools in IDEs. Gang of four patterns we take for granted were considered esoteric gold plating.

Sure, memory usage is high, but hardware is cheap.

That’s fair, but the difference isn’t about whether we have linters or not. It’s about outcomes.

In the ’90s, inefficiency meant slower code. Today it means 32GB RAM leaks in calculator apps, billion-dollar outages from a missing array field, and 300% more vulnerabilities in AI-generated code.

We’ve automated guardrails, but we’ve also automated incompetence. The tooling got better, the results didn’t.

sert_121 · 3 months ago

I believe its a mix of three factors, (a) lack of transfer of institutional knowledge (b) lesser fundamental incentives for people to get better at fundamental skills/gaps (c) rise in hotfixes as we deal with time/scales that operate much faster, burn faster, and want to expand faster.

All of the above is multiplied 1.3x-1.5x with accelerating ways to get upto speed with iterative indexing of knowledge with llms. I believe we are reliant on those early engineers whose software took a while to build (like a marathon), and not short-sprinted recyclable software we keep shipping on it. The difference is not a lot of people want to be in those shoes (responsibility/comp tradeoffs.