This is why this discussion sometimes frustrates me. A lot of the defects we have are because you aren't willing to pay for the sort of software that wouldn't have defects. It's natural to read that as a sort of cynical accusation, but instead, I mean it straight... you really aren't willing to pay what it would take, and you shouldn't be. A $1000 Facebook-access app for your phone (that still somehow has some sort of economies of scale going for it, but that's another discussion) might not crash on you and might take a lot fewer phone resources, but there's no way it's going to be $1000 better than what we get today for free for the vast bulk of users.
On the flip side, the cavalier attitude developers who are on the very, very low side of the curve, where huge quality improvements can be obtained for very cheap, towards those cheap practices also frustrates me. What do you mean you can't be bothered to run the automated test suite that I have handed you on a silver platter on your build server? Are you serious? How can you pass up something so cheap, yet so powerful? And I don't just mean, how can you not be bothered to set it up, etc... I mean, as a professional engineer, how can you justify that?
"What do you mean you can't be bothered to run the automated test suite that I have handed you on a silver platter on your build server?"
As devil's advocate, why not just run this for me (e.g. on every commit/every push)?
Much like the web usability ethos "Why make me think" - why make me work?
The lower the barrier to testing - ideally zero, it just happens without the dev having to do anything - the more testing will happen.
I don't often get the chance to set things up this way, but when I do, each dev works in their own git branch, and sends a pull-request with their changes. The test server(s) then run the complete test-suite on the branch, and either note the PR with "Tests passed" or emails the dev with "Tests failed" and the reasons. Devs don't need to think about running tests, reviewers/release managers don't need to even consider PRs until the "Tests passed" message shows up…saves time and effort for everyone, and improves code quality. The cost is simply the initial setup time.
"As devil's advocate, why not just run this for me (e.g. on every commit/every push)?"
In my real-life experience with a multiple-team environment, which is where the question came from, my running the tests doesn't do any good if you're going to consider it "my" server and simply ignore the results.
The key point here isn't a technical one. The key point here was, as an professional engineer, how can you justify not taking such a great bang/buck quality option that will far, far more than pay for itself? Explaining how I can be a professional engineer on your behalf more than misses the point.
Keep in mind that this level of testing sometimes isn't available at any cost - my company, for example, even if we were awarded a million-dollar-plus contract for the product we already build, would not be able to come up with the stringent testing that those NASA engineers use.
I am 90% sure that actually taking any organisation and committing to good known process will raise the game by orders of magnitude - so technologies supporting and enforcing said process will be of benefit
And I think the process looks like this
1. Written requirements up front
2. Total isolation / integration points defined and contractually enforced
3. Test harnesses built first
4. Per romance and event metrics built in
#1 is never going to happen. It is a fact of life that if you wait until having anywhere near 99% of understanding of the problem space, you will be driven out of market by the guy that did a quick prototype with mere ~70% and iterated from there. A second fact of life is that people know this and will strong-arm their pet feature into any requirements spec whenever they fell they can get away with it.
#2 and #3 might be feasible, but they will require a massive shift of perception across most stakeholders. It's a politics game, and you will need the perennial support of a very influential sponsor to push through the feet dragging phase.
#4 Might be easier to sell, but still require time and effort to implement. In a sense, this is ultimately also a political matter.
We know how to write software that comes arbitrary close to perfection. But as defects asymptotically approach zero, cost skyrockets.
The interesting question is what technologies can bend that cost/quality curve.