How to Not Die by a Thousand Cuts: Rethinking Software Quality
How to Not Die by a Thousand Cuts. Or, How to Think About Software Quality
I argue that software quality is not the sole responsibility of QA teams but a collective duty shared across every function in a product's lifecycle. By examining how linear workflows compound risks and delay feedback, I explore why organizations often fail through incremental corner-cuts. We must embrace the reality that software is infinitely mutable and requires constant, graceful adaptation to avoid a slow, painful degradation.
The saddest way it can unfold is a slow painful degradation without healing succour meaning or hope. The proverbial death by a thousand cuts.
- Bratmon
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.
- conqrr
If there is a place that is hiring and cares about Software Quality, I'll take a 70% paycut to work there.
- bulatb
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, and 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 just a way of lending undue weight to an opinion, a fact about the speaker, not the subject.
- Multicomp
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.
- tomhow
Previously...
How to think about software quality (2022) - https://news.ycombinator.com/item?id=39490543 - Feb 2024 (66 comments)