Previously...
How to think about software quality (2022) - https://news.ycombinator.com/item?id=39490543 - Feb 2024 (66 comments)
How to think about software quality (2022)
31–40 of 59 posts
Re: How to think about software quality (2022)
#32Earlier quoted context omitted.
Well that's a pretty contrived example. There are fair amount of requirements that can be predicted as "possibly coming" in a given problem space, and a good design typically takes them into consideration and plans contingencies such that a design doesn't crumble.
It's extreme to demonstrate the point, but it's not contrived. Realtime deadlines are a completely normal requirement for the systems I work on. I have change reqs on my desk right now that specify a full reboot back to network responsiveness in <=300ms. That definitely changes how the system is designed.
It being extreme is what makes it contrived.
It's also a requirement programmers often overemphasise due to the McNamara fallacy.
Re: How to think about software quality (2022)
#33Earlier quoted context omitted.
If the design is so inflexible that a single requirement shift destroys it, then it wasn't a good design.
That's a refutation of agile, Vibe Coding and the last 25 years of the software industry. One of my own quality metrics that almost everyone rejects is a "a good design is a design where a change that seems like a small change to management is... a small change" It plays out like this. To get to product-market fit you are going to have to zig and zag 20 times. Everybody optimizes for the first step of this journey an…
>It plays out like this. To get to product-market fit you are going to have to zig and zag 20 times. Everybody optimizes for the first step of this journey and then on the second step they optimize for that... and by step 5 or so the archiecture is exhausted and you have no hope of getting to step 20.
It not being "exhausted" is just what distinguishes a good programmer from a bad one. If you're good you can keep a lid on tech debt in the face of rapidly changing requirements. If you suck at it, well... you can't.
>The rare team that is looking ahead 20 steps is the one that survives.
lol no good software engineering means assuming that you don't have a crystal ball (because you never will) and building accordingly.
This usually means YAGNI, minimizing up front design and refactoring aggressively. These are the things that keep you agile enough to move in many different potential directions in response to different potential futures.
The time when this really got rammed home for me was working on a startup where a political black swan event ended up changing key requirements of our software overnight. This pulled the optimal architecture in a wildly different direction to where we anticipated it was going in the previous week.
Re: How to think about software quality (2022)
#34Earlier quoted context omitted.
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 pri…
Why are people so reticent to name companies, even when they're praising them?
Because signaling is more important to them than helping
Re: How to think about software quality (2022)
#35Quality 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.
Re: How to think about software quality (2022)
#36Quality 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, preferenc…
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".
Re: How to think about software quality (2022)
#37Quality 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, preferenc…
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 i…
Yay! I've argued this a few times here and it's been, uh, perceived as low quality.
I think "objective quality" can always be re-framed in terms of fitness. "Quality" is just not anything the fitness function measures, so it can't.
It's hard to really make the case because of course there's something real that people mean, colloquially, and it's totally valid. Lots of things objectively have properties most people would agree show quality. That's where it is, it's right there!
But all those properties can be described without the use of "quality" by just reciting every fact about the thing. The only thing that will be left, the only thing you can't communicate that way, is what the person thinks about those facts.
Re: How to think about software quality (2022)
#38Earlier quoted context omitted.
It's extreme to demonstrate the point, but it's not contrived. Realtime deadlines are a completely normal requirement for the systems I work on. I have change reqs on my desk right now that specify a full reboot back to network responsiveness in <=300ms. That definitely changes how the system is designed.
It being extreme is what makes it contrived. It's also a requirement programmers often overemphasise due to the McNamara fallacy.
Contrived does not mean unrealistic. I have seen many extreme requirements come down on short notice. Over time, the peter priciple guarantees that there will be a middle manager that miscommunicates an agenda they dont fully understand, then push an emergency change down the hierarchy.
Re: How to think about software quality (2022)
#39This 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.
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.
Re: How to think about software quality (2022)
#40Earlier quoted context omitted.
If the design is so inflexible that a single requirement shift destroys it, then it wasn't a good design.
That's a refutation of agile, Vibe Coding and the last 25 years of the software industry. One of my own quality metrics that almost everyone rejects is a "a good design is a design where a change that seems like a small change to management is... a small change" It plays out like this. To get to product-market fit you are going to have to zig and zag 20 times. Everybody optimizes for the first step of this journey an…
Nope not true at all (30+ years of experience here working on very large scale software).
The whole point of being agile is to design your software architecture to be agile. That's what I do. And it works.