Yhwhsman
Yhwhsman
The process of writing software is not a manufacturing process; it's a design process, and often the design of something very complex that should meet unexpressibly complex and ever changing, frequently conflicting, demands.
For those of us who delight in new design challenges, this has been a source of much fun, and a fair bit of money, the last few decades.
There is a manufacturing element of software production, but it is trivial, and provides no feedback on the quality of the software. It's making copies of CD's.
Normal manufactured physical objects, like toasters, TVs, and cars, require quite a bit of custom manufacturing setup, which will help weed out bad designs. And items that have typically high quality, such as cars, have gone through years, decades, even a century of design refinement, gradually improving the quality.
In software, I can and have sent stuff directly from my initial design and coding, done in a single night, with no feedback other than perhaps a compiler telling me my coding was syntactically correct, directly to the end user.
Software suffers from a curse and a blessing. The blessing is that it is vastly more flexible, maleable, capable of complex logic than anything formed of steel, wood or plastic. The curse is ... same thing.
Even if someone got a piece of software "perfect" or nearly so, it wouldn't take a minute for someone to want it to do more, or behave differently, or adapt to other circumstances.
Just as politicians fall prey to the fallacy of "but we have to do something about ...", so do purveyors of software quality improvement tools and products rely on software producers and consumers falling prey to the "but we have to do something to improve software quality.
As with other more complex human disciplines, the best measure of success is not the tool nor the process, but rather the competence and integrity of the producer.