Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Hey Siri, is my app doing what I wanted it to do?by effnorwood
- Siri: brb, asking my agents... Hold my beer.
- Siri: Yes, but each action takes 10 minutes to resolve and your users are jumping out of their windows after dealing with your software.
Programmer: Great, my software works!
by rationalist - (2022)by Okkef
- (edited 2023) agreed mods should append a year given how fast things have been changingby chrisweekly
- Maybe we could take a page from the SWEBOK here, which contains a lot of previous thinking on this topic.
- That’s great, but how do I fix my motorcycle?by sshine
- Testing is not "Quality Assurance".
If I got nothing else out of TFA, at least I could raise my hands and shout an "amen!".
by mikestew - Friend!
Alas, having died on that hill one too many times, I can be with you in solidarity, but not on the hill. No, not again.
- Previously...
How to think about software quality (2022) - https://news.ycombinator.com/item?id=39490543 - Feb 2024 (66 comments)
by tomhow - Quality is what we call the difference between what succeeds and what we wish succeeded. It's a measure of how closely the opinion of the person saying "quality" aligns with what is actually rewarded by the fitness function that objectively exists. The only thing you've learned when you hear "quality" is what the speaker thinks is good, not anything about the subject.
Quality does not exist until a (person, preference, subject) pairing happens. It's not real. It's literally not a thing. It's just a name for mixing up your is and ought.
When someone saying "quality" can point to the specific property that makes the subject quality, they're almost always pointing to what is, from the perspective of the fitness function, inefficiency, a waste of energy and effort, more spent than the system rewards.
Anyone who spends a lot of effort building skills to get particular results is going to believe those results are important, at least a necessary part of success, if not the whole definition. When people who did not put in the effort keep succeeding without those results, "quality" becomes the cope. It's shoddy work. They did it wrong. They cheated somehow.
And yet they succeeded.
Because "quality" is what a person says when is and ought don't match, a fact about the speaker, not the subject.
by bulatb - I agree.
I think the only time quality might be objective is when there's a planned "ought", like a required feature that needs to be implemented later.
From that perspective, the "quality" could be measured in how easy it will be to implement that, in a "total effort" sense (subjective I suppose), where "low quality" might require a whole rewrite of big sections, where "high quality" would have the required stuffs in place (maybe abstractions, or maybe even placed where spaghetti would fit nicely) to make it "easy".
by nomel - If there is a place that is hiring and cares about Software Quality, I'll take a 70% paycut to work there.by conqrr
- I've just accepted the fact that every tech company is just a dumpster fire.by dudul
- You would have liked the last place I worked before retirement. Full-on software test team and everything. Private offices, too. Don't get me wrong, there were warts (oh, were there warts), but overall it was a good time. It wasn't a 70% pay cut, but the cut was considerable in comparison to what I was accustomed to. I didn't care, I was nearing retirement, and my "I'd take a pay cut if..." was the aforementioned private office.
But the company got sold to a conglomerate before I left, so I can't guarantee that culture is still there.
by mikestew - Gene Kim wrote the DevOps Handbook and I think was at least involved in the related DORA and Phoenix Project and Unicorn Project office narrative books. Between those and the Google SRE book, I feel very well placed to have continuing value in the SDLC pipeline for wrangling the oncoming armies of Jr Developers-as-AI-agents-and-sometimes-humans into alignment. I also recommend System Design Interview 1 and 2 books by Xu for logical system design refurbishment, Designing Data Intensive Applications for most company programs, and Hexagonal Architecture Explained by Cockburn for finally getting something as small as a class or module to something as large as an entire Information System to have clear modular boundaries, without needing to do fuzzy pattern matching around half-remembered SOLID principles and GoF design patterns or trying to blindly apply 12 factor app design principles.
Quality used to take a back seat because there was so much legwork to do. AI has reduced the cost to be excellent, so let's be as excellent as our environments let us.
by Multicomp - Great book recommendations (I have read parts of the Google SRE book and Designing Data Intensive Applications)! I will also add a couple gems that I don't see often-cited: Simple Object-Oriented Design by Mauricio Aniche and Secure by Design by Dan Bergh Johnsson, Daniel Deogun, and Daniel Sawano. Both have a lot to offer in terms of software design and maintaining complexity. I also liked Refactoring to Patterns by Joshua Kerievsky.by equinumerous
- This article is very rambling and somehow manages to miss the most important driver of reduced software quality: shifting requirements.
You can have the most beautiful perfect design that leverages the greatest abstractions in the world, and then have it all entirely destroyed by a single requirement shift that totally kills your abstractions.
by Bratmon - If that ever happens to you, you're doing it wrong.
I've spent 30+ years building large-scale software, and it has never happened to me. Good software design lets you accommodate even major requirement changes with minimal changes to the code.
- If the design is so inflexible that a single requirement shift destroys it, then it wasn't a good design.by evan_a_a
- I think a good way to put it is this: every abstraction is a gamble.
There are likely a lot of safe bets, but even choices that once made sense can become an issue later.
by timw4mail - Post author here. Guilty as charged re: rambling. Brevity is not my strong suit.
To the second point, I'd say I'm in violent agreement with you. In fact, my whole thesis is that because software mutates all the time, it is observed that successful software mutates successfully.
Obnoxiously quoting self:
> Unlike all other machines, it is pure concept, and as such it is infinitely malleable and mutable. And mutate it does, all the time.
and several paragraphs below that...
> Not only does all software mutate, we also end up performing all kinds of deep surgery on the organisation that produces it. The whole thing—product and org—is simultaneously flexed, reconfigured, and even totally redesigned in-place with rapidity that is very uncommon in other industries. Why? Because software fundamentally is peoples' thoughts being played on repeat.
- well you cannot design for the unpredictable, but well designed code will make refactoring easier anywaysby tcfhgj