Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to think about software quality (2022)

evalapply.org

Post reply on HN
Print view View original

51–59 of 59 posts

Re: How to think about software quality (2022)

#51

Post by timw4mail »

Bratmon wrote: post #13

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.

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.

Re: How to think about software quality (2022)

#52

Post by cindyllm »

PaulHoule wrote: post #18
evan_a_a wrote: post #16

Earlier 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…

[dead]

Re: How to think about software quality (2022)

#53

Post by phailhaus »

deterministic wrote: post #43
phailhaus wrote: post #21

Earlier quoted context omitted.

Completely untrue. Every design can be destroyed by a single poorly-thought out requirement. I can take down Facebook's design just by saying "any edit must immediately be visible to all users".

That's a straw man argument. Your new requirement is physically impossible. No software team can break the laws of physics. So the real question is what exactly do you mean by "immediately"? There are many answers with different pros/cons and cost. And I bet the solution won't impact 99% of the software Facebook has already written.

My new requirement is NOT physically impossible. I did not mean "immediately" as in "zero milliseconds", it meant strong read-after-write consistency. It makes facebook so slow and unscalable as to be unusable. Facebook deliberately decided that stale reads are worth it for responsiveness and scale.

Re: How to think about software quality (2022)

#54

Post by AlotOfReading »

pydry wrote: post #32
AlotOfReading wrote: post #28

Earlier 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.

You missed the point of the example. The parent said any design that has to change with a single requirement shift is a bad design. So I gave a requirement that virtually any design would have to change to accommodate. It doesn't preclude the existence of other, more plausible requirements that shift designs. I even provided a real example of one, which you've ignored.

Re: How to think about software quality (2022)

#55

Post by nomel »

bulatb wrote: post #37
nomel wrote: post #36

Earlier quoted context omitted.

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 wo…

> .. perceived as low quality.

What you're saying requires someone looks past some existing categorizations that they've formed. I suspect you're not as vulnerable to categorization as the usual person, so this probably happens often. ;)

Re: How to think about software quality (2022)

#56

Post by deterministic »

phailhaus wrote: post #53
deterministic wrote: post #43

Earlier quoted context omitted.

That's a straw man argument. Your new requirement is physically impossible. No software team can break the laws of physics. So the real question is what exactly do you mean by "immediately"? There are many answers with different pros/cons and cost. And I bet the solution won't impact 99% of the software Facebook has already written.

My new requirement is NOT physically impossible. I did not mean "immediately" as in "zero milliseconds", it meant strong read-after-write consistency. It makes facebook so slow and unscalable as to be unusable. Facebook deliberately decided that stale reads are worth it for responsiveness and scale.

So your argument is that no solution could satisfy your new requirement, not even if Facebook rewrote the entire system from scratch.

If that's the case, then your example doesn't really address what we're discussing: whether software can be designed to remain flexible under realistic requirement changes.

A stronger argument would be to give an example of a realistic requirement change that would force all possible software architecture to be rewritten from scratch. Do you have an example like that?

Re: How to think about software quality (2022)

#57

Post by deterministic »

xedrac wrote: post #41
deterministic wrote: post #39

Earlier quoted context omitted.

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 you're using Lisp, then sure. If you're using C++, then chances are you're going to have to heavily overengineer the thing to cover all possible requirement changes. That comes at a great cost - in most cases, you are unlikely to benefit from the overly abstract design, but you will pay for that additional complexity for the life of the project. I am convinced that you are better off designing the project to solve…

> If you're using Lisp, then sure.

So are you saying Lisp somehow makes software flexible enough to handle any requirement change, no matter how badly it's written?

Really?

Lisp doesn't have any unique feature that makes this possible. Macros, meta programming, and single type systems all exist in other languages too.

> If you're using C++, then chances are you're going to have to heavily overengineer the thing to cover all possible requirement changes.

I disagree. My experience has been the opposite.

I maintain a large C++ codebase used by companies around the world. I spend almost all my time adding features and almost none fixing production bugs. The code is flexible because it's well designed and well tested.

The language isn't what's important. Good design and good testing make software flexible. Poor design doesn't, no matter what language you use.

Re: How to think about software quality (2022)

#58

Post by jkmcf »

adityaathalye wrote: post #44
Bratmon wrote: post #13

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.

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…

I'm sorry this blog post was so long, I didn't have time to make it shorter.

Re: How to think about software quality (2022)

#59

Post by phailhaus »

deterministic wrote: post #56
phailhaus wrote: post #53

Earlier quoted context omitted.

My new requirement is NOT physically impossible. I did not mean "immediately" as in "zero milliseconds", it meant strong read-after-write consistency. It makes facebook so slow and unscalable as to be unusable. Facebook deliberately decided that stale reads are worth it for responsiveness and scale.

So your argument is that no solution could satisfy your new requirement, not even if Facebook rewrote the entire system from scratch. If that's the case, then your example doesn't really address what we're discussing: whether software can be designed to remain flexible under realistic requirement changes. A stronger argument would be to give an example of a realistic requirement change that would force all possible s…

> So your argument is that no solution could satisfy your new requirement

No, read my comment again. They could do it but it would absolutely destroy the responsiveness of the app.

Post reply on HN