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

11–20 of 59 posts

Re: How to think about software quality (2022)

#11

Post by 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.

Re: How to think about software quality (2022)

#13

Post by 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.

Re: How to think about software quality (2022)

#15

Post by tcfhgj »

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.

well you cannot design for the unpredictable, but well designed code will make refactoring easier anyways

Re: How to think about software quality (2022)

#16

Post by evan_a_a »

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.

Re: How to think about software quality (2022)

#18

Post by PaulHoule »

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.

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 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. The rare team that is looking ahead 20 steps is the one that survives.

Re: How to think about software quality (2022)

#20

Post by mikestew »

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 private office.

But the company got sold to a conglomerate before I left, so I can't guarantee that culture is still there.

Post reply on HN