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

41–50 of 59 posts

Re: How to think about software quality (2022)

#41

Post by xedrac »

deterministic wrote: post #39
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 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 the problem in front of you, and then if the requirements shift, pay the cost to solve the new problem, rather than forever pay the cost of solving a host of unrealized problems.

Re: How to think about software quality (2022)

#42

Post by xedrac »

pydry wrote: post #33
PaulHoule wrote: post #18

Earlier quoted context omitted.

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

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

Every drop of tech debt (aside from AI slop) I have ever been a part of has manifested simply because some manager or executive made the decision to sacrifice quality for short-term speed. Sometimes this looks like an unskilled developers producing something that management won't let you fix. Sometimes it's a completely unrealistic deadline that requires extreme measures to meet. If you are able to keep a lid on tech debug in the face of rapidly changing requirements, it likely means that you have enough slack in your job to do so.

Re: How to think about software quality (2022)

#43

Post by deterministic »

phailhaus wrote: post #21
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.

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.

Re: How to think about software quality (2022)

#44

Post by adityaathalye »

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 does, all the time.

and several paragraphs below that...

> Not only does all software mutate, we also end up performing all kinds of deep surgery on the organisation that produces it. The whole thing—product and org—is simultaneously flexed, reconfigured, and even totally redesigned in-place with rapidity that is very uncommon in other industries. Why? Because software fundamentally is peoples' thoughts being played on repeat.

Re: How to think about software quality (2022)

#45

Post by adityaathalye »

dudul wrote: post #12
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.

I've just accepted the fact that every tech company is just a dumpster fire.

Some are dumpster fires inside oil spill fires on top of a lethally radioactive surface. Once I had such a client from the depths of hell. Handling lower/middle-income people's wealth. Doing money math with floating point arithmetic. In Javascript. Minimum "function" line size of one hundred lines, with several four hundred line "functions". With "functional" idioms like map/filter etc. inside said functions, except hang on why is the mapping function making network calls? To a workflow orchestrator? Which is then calling out into... mongodb. To... do the money math based on a flag in the `meta` field of a user object. A flag that is being set and reset at least twice, directly in the four hundred line function I'm staring at with bleeding eyes, and, but I can't bear to jump to definitions and see where else it might be toggled from the calling code? Please don't make me do it.

Um, and this was just one aspect of their software organisation.

Four hundred line floating point dumpster fires, inside a gawdawful dog-slow software system, because, nearly a hundred "microservices" (about two per engineer, I counted), being somehow managed via an elaborate AI of calendar tetris, because everyone in the company was somehow fine with it, because they were mostly young and it was their first or second job and they probably didn't know any different, the poor sods.

Re: How to think about software quality (2022)

#46

Post by adityaathalye »

adityaathalye wrote: post #45
dudul wrote: post #12

Earlier quoted context omitted.

I've just accepted the fact that every tech company is just a dumpster fire.

Some are dumpster fires inside oil spill fires on top of a lethally radioactive surface. Once I had such a client from the depths of hell. Handling lower/middle-income people's wealth. Doing money math with floating point arithmetic. In Javascript. Minimum "function" line size of one hundred lines, with several four hundred line "functions". With "functional" idioms like map/filter etc. inside said functions, except…

Plot twist: Newly-hired head honcho of software was going to fix it all with Kubernetes. Peak transaction volumes of about ten per minute.

Once the project ended, I never looked back and wiped all but the essential lessons from memory.

I can't name them because my brain legit refuses to look up the name. I know it's there somewhere in the periphery. And even if it did pop back, it shall remain nameless, for harm could come to many innocents.

Re: How to think about software quality (2022)

#47

Post by adityaathalye »

mikestew wrote: post #17

Testing is not "Quality Assurance". If I got nothing else out of TFA, at least I could raise my hands and shout an "amen!".

Friend!

Alas, having died on that hill one too many times, I can be with you in solidarity, but not on the hill. No, not again.

Re: How to think about software quality (2022)

#49

Post by pydry »

xedrac wrote: post #42
pydry wrote: post #33

Earlier quoted context omitted.

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

> 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. Every drop of tech debt (aside from AI slop) I have ever been a part of has manifested simply because some manager or executive made the decision to sacrifice quality for short-term speed. Sometimes this looks like an unskilled developers producing something that management won't let yo…

Asking permission to fix tech debt is a rookie mistake. You need to bake the fixes into the ticket.

Half of my job as a lead is to cajole, threaten and convince juniors into spending 5 days on a ticket to do it properly rather than spending 2 in order to get brownie points for "looking" productive.

Ive had more than one call where the junior says "we don't have time for that" and I have to call in the PM to let them know that it's OK, we do.

There are environments where management put so much pressure on you that you can't help but deliver crap but not everywhere has to be like that.

Re: How to think about software quality (2022)

#50

Post by pydry »

Supermancho wrote: post #38
pydry wrote: post #32

Earlier quoted context omitted.

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.

No, but programmers fetishize speed. Customers usually value it far, far less than many programmers think.

Ive seen many a programmer gagging to rearchitect to speed up an app 2x or 3x when there are 9 other things a customer genuinely wants first and the programmer refuses to believe it.

Most recently it was on a RAG system where an extra 500ms would surely have been appreciated but the right answer mattered 100x more.

Post reply on HN