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

21–30 of 59 posts

Re: How to think about software quality (2022)

#21

Post by phailhaus »

evan_a_a wrote: post #16
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.

If the design is so inflexible that a single requirement shift destroys it, then it wasn't a good design.

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

Re: How to think about software quality (2022)

#22

Post by stavros »

mikestew wrote: post #20
conqrr wrote: post #3

If there is a place that is hiring and cares about Software Quality, I'll take a 70% paycut to work there.

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?

Re: How to think about software quality (2022)

#23

Post by AlotOfReading »

evan_a_a wrote: post #16
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.

If the design is so inflexible that a single requirement shift destroys it, then it wasn't a good design.

Then I guess no design is good. Here's an easy example: take any software system you can think of. Let's add a single new requirement: it must produce an output in 1us. I'll bet your system has to change.

Re: How to think about software quality (2022)

#24

Post by equinumerous »

Multicomp wrote: post #11

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…

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.

Re: How to think about software quality (2022)

#25

Post by GuB-42 »

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…

The problem is that you don't know in advance what the 20 steps will be, and you may spend time solving the wrong problem.

Make step 1 as simple as possible, step 1 is small and changes are cheap, you can even rewrite everything with little effort, no need to prepare for anything at this point.

Step 2-4 will inevitably break something, no big deal, rewrite the parts that need to be rewritten, it is still cheap.

At step 5 rewrites are starting to get costly, but now you have a better idea of what is here to stay, so it is now time to invest in things like regression testing, style guides, etc...

At step 10, you have quite a history, rewrites become a really bad idea, no turning back after that. So now it is time to think about the future. The difference from doing that in step 1 is that you now have 10 steps of experience and only need to look ahead 10 steps.

Re: How to think about software quality (2022)

#26

Post by inigyou »

stavros wrote: post #22
mikestew wrote: post #20

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

It can be seen as dark advertising. Because it is.

Re: How to think about software quality (2022)

#27

Post by regular_trash »

AlotOfReading wrote: post #23
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.

Then I guess no design is good. Here's an easy example: take any software system you can think of. Let's add a single new requirement: it must produce an output in 1us. I'll bet your system has to change.

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.

Re: How to think about software quality (2022)

#28

Post by AlotOfReading »

regular_trash wrote: post #27
AlotOfReading wrote: post #23

Earlier quoted context omitted.

Then I guess no design is good. Here's an easy example: take any software system you can think of. Let's add a single new requirement: it must produce an output in 1us. I'll bet your system has to change.

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.

Re: How to think about software quality (2022)

#29

Post by akoboldfrying »

regular_trash wrote: post #27
AlotOfReading wrote: post #23

Earlier quoted context omitted.

Then I guess no design is good. Here's an easy example: take any software system you can think of. Let's add a single new requirement: it must produce an output in 1us. I'll bet your system has to change.

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.

Right, the point is that GP's definition should take the nuance you mention into account (namely, that some types of changes are more likely, and thus more important to handle nicely, than others).

Re: How to think about software quality (2022)

#30

Post by Rzor »

AlotOfReading wrote: post #23
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.

Then I guess no design is good. Here's an easy example: take any software system you can think of. Let's add a single new requirement: it must produce an output in 1us. I'll bet your system has to change.

I think you are interpreting his claim in the most extreme possible way. You are doing the equivalent of asking a civil engineer what if his bridge needs to support flying cars, or weight half as much while carrying ten times the load. Of course there are architecture breaking requirements, but his point still stands for reasonable and foreseeable changes. If it doesn't survive that, then it wasn't a good design begin with.
Post reply on HN