Can you explain more about how high quality engineering software projects do not rely on programmer's experience and intuition, but instead follow formulaic rules and achieve excellent?
From my limited reading, it seems that most "mission critical" software is achieved by applying a lot of resources, especially testing, to the project. Not to mention having a very well-defined (and relatively unchanging?) problem space.
Surely, if there were engineering principles that enabled folks to reliably create high quality software, we wouldn't see the horrible failure rates across all sorts of software projects.
I work in the area of critical infrastructure software.
There's no special software engineering sauce that gets used. But there is a dedicated commitment to careful code review, and exhaustive testing, as well as a very rigorous process for defect handling. We have a dedication from the top down to ensure our stuff doesn't break our customers. We don't have a "software pirate ninja rock star" culture, we have a culture of careful work.
Doesn't mean null pointers don't get accessed, or that weird code doesn't show up. It just means that hey, we worked real hard to ensure that these issues are minimized. Quality is a journey, and every day we have to work on it.
This is a great article about how this sort of stuff is done and the kind of culture that you want to cultivate. It's a bit dated, but still solid.
This is mostly semantics, but in general attributes like "dedicated commitment" are hallmarks of a "craft" practiced by individuals. "Engineering" tasks are things like "processes" and "models". So really, I think you're agreeing more than disagreeing.
And the "software pirate ninja rockstar" thing is a shameless strawman.
Processes are nothing without people dedicated to following them. Models are unreliable without taking care to craft a reliable system.
I don't really consider disciplined programming to be a branch of engineering. While I don't have a sophisticated metaphysics of code, it seems that there is an essential ontological difference between "engineering" a software system and "engineering" a bridge or a chemical process.
Richard Gabriel once suggested the idea of a MFA in software, and I think that he is onto something.
I have done both hardware and software engineering, and I see no difference.
It is difficult to put into words, but I would say that the heart of engineering is the discipline of understanding how and why something is useful, as distinguished from feelings or hopes about its utility.
An MFA in software is pretty much the opposite of engineering. Engineering is not a matter of taste or opinion, it is about creating such hard sparkling truths that opinion would be superfluous.
From what I saw, most mission critical software is done in such a way that a single programmer can understand the whole system starting from microcode instructions up to the control parts.
Lots of static analysis also helps, as well as systematic human review of any code, test, or test result.
The best example I witnessed was an engine control system (FADEC software) written in a dialect of ADA called Spark. The code was so clear that it was self-explaining, and a requirements database could explain any given statement in the program. Spark has some nice properties (e.g. no recursion to make it possible to check stack depth limits statically...)
So while more manpower is an important element, it is not the only one. Simplifying the problem space to an extreme is also essential.
You seem to be saying that engineering does not require experience and intuition? I would think that in this case becoming an engineer would be a bit simpler than degree + exam + several years experience[1] + another exam.
From my limited reading, it seems that most "mission critical" software is achieved by applying a lot of resources, especially testing, to the project. Not to mention having a very well-defined (and relatively unchanging?) problem space.
Surely, if there were engineering principles that enabled folks to reliably create high quality software, we wouldn't see the horrible failure rates across all sorts of software projects.