High-Quality Software Engineering (2007) • Hacker News Board

Re: High-Quality Software Engineering (2007)

#41

Post by ChrisMarshallNY » Fri, May 17, 2024, 10:24 AM UTC

lloydatkinson wrote: post #39

ChrisMarshallNY wrote: post #7

I was explaining this to a friend who's a top-shelf cabinetmaker. He was telling me how he would sell high-quality cabinets to homeowners, basically by building a "dream kitchen," that far exceeds their budget, then backing down, by removing features, until they have something that exceeds their original budget, but would still be quite good, and that they want. He was saying that I should use his methodology. I expl…

How did he react? I imagine he was horrified.

Actually, he understood perfectly. He was a businessman, as well as a craftsman, and understood that this is par for the course, in many successful businesses.

I believe that it's vital to have a stake in Quality, or it won't happen.

Re: High-Quality Software Engineering (2007)

#42

Post by farley13 » Sat, May 18, 2024, 11:20 PM UTC

betenoire wrote: post #28

ffitch wrote: post #27

Earlier quoted context omitted.

good point. perhaps code quality and product quality are different things.

Right, and they are, that's my point. Quality isn't a single attribute of a system, it's a judgement call based on objectives. The objectives of a business selling software, and that of engineers is something else. Sometimes maintenance, sometimes extensibility, sometimes exploration, sometimes just seeing if something is possible. Quality correlates to the objective, and in my experience, many software engineers hav…

There is a lot to be said for getting outside the four walls of a business (or org) to evaluate things. If it's not visible outside those walls (software buggy enough to lose customers) and doesn't introduce significant future risk to the business (competition can move faster than you) it's probably good enough. The real trick of course is predicting and communicating why you think one of these is true. It's an essential problem of commercial software dev.

Re: High-Quality Software Engineering (2007)

#43

Post by angarg12 » Sun, May 19, 2024, 6:07 PM UTC

> Here’s a little-known secret: most six-nines reliability software projects are developed using a waterfall methodology.

I've designed and deployed Tier 1 services for a Big Tech company, and here's is a little-known secret: when nothing changes, our reliability is higher than six-nines.

Last year I measured our uptime during Black Friday for fun. Our error rate was measured in scientific notation because the number was so small. We didn't do any deployments or changes during that period.

When you operate in a steady state it's easy to achieve zero errors, and most downtime comes from random failures in hardware, i.e. servers crashing or network blips (which, operating at scale, are relatively common).

So my and other's personal experience is that most outages are due to changes in the software, dependency outages, or the rare large scale event that completely kills your SLA (e.g. a whole AWS region is down). Taming these is at the essence of reliable software.

Whoever tells you that the best software is made using waterwall methodologies from a fixed and never changing set of specifications, lives in a fantasyland alien to the vast majority of developers.