If you can get 100 experts to agree on something then you've cracked a much harder problem than software quality.
If 100 experts can't find a problem with something, it's probably perfect. Unfortunately, this is impossible.
I know where you're going with this, but here's a twist:
A CEO who cares about interface _design_ is path to micromanaging and pain. A CEO should care about interface _designers_, who are (hopefully) the people trained on how do it well.
Even better: CEOs should care about developers with UI/UX skills, because too often CEOs adopt designers like a pet and keep them busy 24/7 asking for mockups.
That's how Apple blew up into a trillion dollar company.
Plenty of other CEOs have thought the secret to Apple's success was micromanaging like Steve Jobs and been proved very wrong.
The best CEOs hire people smarter than them (in their respective disciplines) rather than assuming they always know best.
>Quality is the absence of problems
A low quality code base can be problem free if surrounding circumstances are forgiving enough. Conversely, a high quality codebase can have a lot of problems in difficult circumstances.
I haven't thought about it long enough to have a definition of quality that I'm really happy with, but I think a "resilience to hardships" would be a better definition of quality. Hardships can come in many forms, and often you're prepared for some of them but not all. Occasionally you'll be prepared for hardships that never occur. There is something to be said for being resilient against the correct kinds of hardships, which is why I'm not entirely pleased with my definition either.
But absence of problems is not it. That might be entirely circumstantial and is therefore orthogonal to quality.
There isn't some intrinsic value to software, it's gotta be used by somebody
Properly speaking, that would be a characteristic of the entire production process, including the people, rather than a property of the code itself. (At least for now. Stay tuned with AI for further updates.) Still, you'll see it in the code.
Software very rarely exist in a vacuum
i disagree, think about what defines a problem. Not being maintenable, readable, performant etc could be problems or may not be depending on the software requirments.
> Occasionally you'll be prepared for hardships that never occur.
this over-engineering and just as bad as failing to meet a requirement, you're wasting resources that could be spent on something else. In fact, meeting the requirements and only the requirements is requirement #1 ;)
Does this refer only to program behaviour? I figure readability should count toward quality, but it doesn't directly affect program behaviour.
I'm interested in quality, but I didn't find these notes enlightening, and couldn't even finish the article.
“How likely are you to work in this codebase again?”
0 = Least likely 10 = Most likely
For me it means care and attention were paid while developing, the rough edges have been smoothed off for want of a better phrase. This doesn't mean using the latest and greatest framework or library, usually quality will come from a deep understanding of the basics and concepts like design patterns .
You can spot quality code in the same way to can tell a fake Rolex from a real one but the quality of the movement.
That's a "yes and no" thing. Handmade quality, yes, but some companies get pretty good at finding a "sweet spot," between better-than-average quality, and "Rolls Royce" quality.
Source: I worked for a company that was pretty much renowned for Quality. We made stuff that is pretty near the top shelf, but still a rung or two under the top.
It's not easy.
Also, customers are willing to pay for garbage. As long as that continues, garbage producers will drive quality producers out of business.
Some of these are difficult to quantify, but are often the difference between success or failure, in the market.
I constantly encounter “dead” software. Software that is correct, performant, awesome (in some cases), but something that I don’t “want” to use. A “necessary evil.”
That kind of statement doesn’t fly well, in a community of “Inspector 34”s, but it applies to those we like to call “customers.”
Imo this point should be changed to reviewability. Beauty is in the eye of the beholder
And "simplicity" comes to mind. Also not mentioned.
The what? Since when has "the industry" been able to define best-designed, much less agree on it?
Personally I find quality to have a fundamental impact on everything every human does. It affects mental state, motivation, affects ability, necessity, and time to do things, creates or reduces costs, availability of resources, clarifies or complicates, makes life easier or harder, etc. It can save or destroy a business, make someone's life feel easy as pie or insanely frustrating. But it's not always easy to do right; you need a system to apply quality intelligently or you risk your efforts being wasted (https://global.toyota/en/company/vision-and-philosophy/produ...).
^ = from your linked Toyota Production System philosophy
Thanks for that link! I find those two early sentences to be an insightful and relatively complete loop of process.
When considering using automation or ~A.I. we can easily ask: which part of this loop is our addition improving (or messing up)? Where is the balance that works?
As you point out, answering these what-works/quality questions are not solved problems and expertise is needful, but careful consideration does not seem to be a popular mode in our age of fountaining funny money and magic genies.
I grew up in the '60s where the science fiction/future was always: march of progress and you'll have so much time and choices! Now I am in the future and the reality is close to: who has the time?
More insidiously/invisibly: you have plenty of time for endless momentary thrills, but no one has time to make things better.
Once upon a time there were customer complaint departments and the Production System would get fixed. Then it became suggestion boxes and returns. Then pleading for a Return Merchandise Authorization. Then it's your call is valuable to us recordings before click call hangups. Oops, unhappy customer?--give 'em a coupon to keep up the addiction, it's cheaper than Quality Control.
The latest devolution seems like fire the workers but use AI to mesmerize customers, or just mind control ~investors and ~regulators, since who needs cover-our-costs-paying-customers anyway?
Will the pendulum swing back?
Sure you didn't miss one? You can't have an exhaustive list because any of those can be just as true as false depending on the situation.
Instead of picking the ones I disagree with most, I'll just say that low quality is miscommunication. The bugs are a snapshot of the organization.
There are multiple facets to hang concern on that the other stakeholders don't know about or ignore. Your ability to discuss them, plan, and execute is the bottleneck. Everyone has to be on the same page.
This cannot be the sole responsibility of the devs or small isolated teams. Scale is necessary for quality to emerge.