I can easily relate to the frustration behind the crude methodologies that dominate software development these days, but I think the author is missing the crux of the whole issue.
Software is pure thought-stuff. Its complexity knows no bounds. The software universe already has many orders of magnitude more complexity than all physical engineering disciplines combined, and that quantity will continue to grow.
To say that we just need to buckle down, measure things, and design rigorous and optimal methodologies is at best naïve. There is no consistency or reproducibility in software development. Every project is different, the ecosystems in which development is done are constantly shifting, the dependencies are often unknown, the big picture is too complex for any one person to fully comprehend, and individual skill sets vary so much as to make any hope of "optimal" architecture all but impossible.
Contrast with bridge building. Consider the enormous amount of experience and study that has been expended tens of thousands of times to fulfill basically ONE requirement that 99% of the population can easily understand. "It needs to be able to support the weight of the traffic going over it". Think of all the complex load bearing computation, materials science, fluid dynamics, and everything else that goes into meeting this one basic requirement. Sure, nature makes this a challenging task, but at the core you have one simple requirement which you can design your whole process around. You can try different things and over time iterate to optimal processes because the requirements are essentially the same every time.
With software you have no such grounding requirement. On the plus side abstraction allows simple software to be very very simple. However for any software of significant complexity the interactions of concerns and requirements quickly balloons out of control. The only way to manage this complexity is on a case-by-case basis. There are many best practices and common techniques that can be applied to improve the quality, but they all have a cost, and they will all have varying degrees of benefit depending on the project and the team. I'd say NASA has very very good methodologies for ensuring quality, but it costs more than the vast majority of projects could even fathom paying 1% of.
Should everyone that is willing to tolerate some bugs in exchange for a 99% discount tag get out of the software business? Should all the developers just go home and leave software engineering to be practiced and defined by corporations and government programs with 9-figure budgets?
Software is pure thought-stuff. Its complexity knows no bounds. The software universe already has many orders of magnitude more complexity than all physical engineering disciplines combined, and that quantity will continue to grow.
To say that we just need to buckle down, measure things, and design rigorous and optimal methodologies is at best naïve. There is no consistency or reproducibility in software development. Every project is different, the ecosystems in which development is done are constantly shifting, the dependencies are often unknown, the big picture is too complex for any one person to fully comprehend, and individual skill sets vary so much as to make any hope of "optimal" architecture all but impossible.
Contrast with bridge building. Consider the enormous amount of experience and study that has been expended tens of thousands of times to fulfill basically ONE requirement that 99% of the population can easily understand. "It needs to be able to support the weight of the traffic going over it". Think of all the complex load bearing computation, materials science, fluid dynamics, and everything else that goes into meeting this one basic requirement. Sure, nature makes this a challenging task, but at the core you have one simple requirement which you can design your whole process around. You can try different things and over time iterate to optimal processes because the requirements are essentially the same every time.
With software you have no such grounding requirement. On the plus side abstraction allows simple software to be very very simple. However for any software of significant complexity the interactions of concerns and requirements quickly balloons out of control. The only way to manage this complexity is on a case-by-case basis. There are many best practices and common techniques that can be applied to improve the quality, but they all have a cost, and they will all have varying degrees of benefit depending on the project and the team. I'd say NASA has very very good methodologies for ensuring quality, but it costs more than the vast majority of projects could even fathom paying 1% of.
Should everyone that is willing to tolerate some bugs in exchange for a 99% discount tag get out of the software business? Should all the developers just go home and leave software engineering to be practiced and defined by corporations and government programs with 9-figure budgets?