That's the one! Thanks for looking it up for me. I sorta felt like it was a bit wrong, but I figured you'd know who I was taking about.
No problem. I simply found it it slightly ironic, that's all.
I had to look up "ethos", and, no, I disagree; it's precisely the ethos which makes it a problem. (Not that I disagree with your statement about low barriers to entry, that's what made getting a software job such a good option when I graduated and the aerospace industry was in a nose dive. But surely you won't argue that the barriers to entry don't affect ethos?)
No, that wasn't the point of "barriers to entry". The point was that a broader pool of talent is going to offer you a wider range of capabilities, a wider discrepancy in methodologies and, with a low barrier to entry, experimentation.
I offered it as a reason behind the core of your argument, which has been: "Look at all these software projects that lack all this documentation and stringent drive toward testing. It's inherent and endemic to the software industry."
Rigorous engineering doesn't rely on delivering a 'bug fix' after the products are already out there. I know, I know, "Hubble" is like the giant anti-example there, but how many other aerospace missions get do-overs? 4 or 5. In traditional hardware engineering, bug fixes are ridiculously expensive. Not so in software, just upload new code.
No, with traditional hardware engineering, bug fixes are ridiculously difficult. Hardware is traditionally not modular, is fixed and static, and incapable of morphing to fit a changing landscape.
What causes them to be expensive is almost entirely related to scope and complexity. The same goes for software. Bug fixes for software can be ridiculously expensive to produce as well. The difference is that the cost of deployment can be low. It's not always low, however. Firmware updates can be very difficult and expensive to deploy.
The consequences aren't thought to be as bad, so it doesn't get as much care as it should. I think the "we'll just send a bug fix" mentality is part of the software ethos, and I think development tools and development strategies should be less reliant on such solutions.
You can surely find an example of software projects that rely upon this mentality. The notion of barriers to entry is involved here: more projects = the higher likelihood you'll encounter it. But guess what? Some of the most celebrated hardware in human exploration had some nefariously terrible hardware bugs.
Bugs are the byproduct of humans interacting together to build something. They are caused by erroneous logic, incompetence, lack of communication, making faulty assumptions, incompatible/conflicting opinions on implementation, etc, etc. None of these things are inherent to software development.
Most reliable software projects rely upon stringent unit testing, and iterating in small scopes so as to allow appropriate code review. The mentality of "let's just release now and bug fix later" is usually pushed by the management of the project or sales people than actual software engineers. It happens
all the time in hardware, too. That's an issue with
project management.
Heck, Mythbusters actually has better documentation than some libraries out there... (Cue Kari: "Oh, we forgot the Newton's laws!")
Same goes for some hardware specs. I don't know how much experience you have with dealing with highly custom or proprietary hardware outside of the aerospace industry, but it can oftentimes lack significant documentation details in its specs. There are also cases where the specs are held for ransom. Again, this is not inherent to software.
As I've said before, your argument so far has been related to the difference in size of the two industries. I do think the points are circular at this point, and each side has adequately made its point. Not to mention that it's wildly off-topic.
