How to not die by a thousand cuts or how to think about software quality (2023)
43 points by adityaathalye 5 hours ago | 23 comments
conqrr 4 hours ago
If there is a place that is hiring and cares about Software Quality, I'll take a 70% paycut to work there.
replymikestew 2 hours ago
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.
replyBut the company got sold to a conglomerate before I left, so I can't guarantee that culture is still there.
Multicomp 2 hours ago
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.
replyQuality 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.
equinumerous 40 minutes ago
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.
replymikestew 2 hours ago
Testing is not "Quality Assurance".
replyIf I got nothing else out of TFA, at least I could raise my hands and shout an "amen!".
throwway120385 2 hours ago
Maybe we could take a page from the SWEBOK here, which contains a lot of previous thinking on this topic.
replyOkkef 3 hours ago
(2022)
replychrisweekly 3 hours ago
(edited 2023)
agreed mods should append a year given how fast things have been changing
replyeffnorwood 4 hours ago
Hey Siri, is my app doing what I wanted it to do?
replyrationalist 3 hours ago
Siri: Yes, but each action takes 10 minutes to resolve and your users are jumping out of their windows after dealing with your software.
replyProgrammer: Great, my software works!
effnorwood 3 hours ago
Hey Siri, my software isn't doing what I wanted it to do. Confirm PRD did not include 10 minute wait times and send my IQ test results again please.
reply
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.
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.
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.