The solutions put forth by you and Nancy and Uncle Bob are not mutually exclusive, but they are missing an important enabler of bad software: management. At the end of the day, good requirements and professionalism take time, aka cost. The potential upside is quality. I say "potential" because the financial success of a thousand startups (despite the failure of 10x that number) has taught us that rewards accrue to those who frequently chose "right now" over "right" when asked about shipping - damn the QA. In that sense, durability requirements of "runs once" vs. "runs a thousand times without failure" are important and frequently difficult to reverse engineer if you got them wrong when you shipped the prototype. But those decisions still need to be made explicitly or they will emerge through bug reports much to the disdain of those management enablers. So that leaves us with requirements, professionalism, and management. Call it organizational dynamics - the single most important cultural attribute is what we call "safety": all else being equal, everyone on the team must feel safe to speak truth to power, because getting to the truth is really what engineering is all about.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
If management wants its devs to produce the cheapest, crappiest, most buggy software on the planet, it's probably next to impossible for individual devs or even a whole team of them to resist that pressure in a significant way and deliver quality product.
The solutions put forth by you and Nancy and Uncle Bob are not mutually exclusive, but they are missing an important enabler of bad software: management. At the end of the day, good requirements and professionalism take time, aka cost. The potential upside is quality. I say "potential" because the financial success of a thousand startups (despite the failure of 10x that number) has taught us that rewards accrue to those who frequently chose "right now" over "right" when asked about shipping - damn the QA. In that sense, durability requirements of "runs once" vs. "runs a thousand times without failure" are important and frequently difficult to reverse engineer if you got them wrong when you shipped the prototype. But those decisions still need to be made explicitly or they will emerge through bug reports much to the disdain of those management enablers. So that leaves us with requirements, professionalism, and management. Call it organizational dynamics - the single most important cultural attribute is what we call "safety": all else being equal, everyone on the team must feel safe to speak truth to power, because getting to the truth is really what engineering is all about.
You make very good points, David.
If management wants its devs to produce the cheapest, crappiest, most buggy software on the planet, it's probably next to impossible for individual devs or even a whole team of them to resist that pressure in a significant way and deliver quality product.
The Boeing MAX 737 root cause was management. Not engineering.