QA and Testing
No. The reason for lousy software lies in two simple words. Inadequate testing.If he's talking about QA, then he's dead wrong. According to studies in all other facets of production, a focus on increasing the quantity of QA will actually increase the number of defects. (That must somehow tie into Heisenburg's Uncertainty Principle, right?) Quality software requires testing, yes, but that should be the responsibility of the developer. Want to make high-quality software? Make the developers think that there is no QA. Even if you sneak some in unbeknownst to them. [ /dev/nul ]
Sorry, I have to disagree here. When you send more mine sweepers into a minefield more mines are found. Does the number of mines in the minefield increase? No, there is still just as many, just the number of known mines increases. What certinaly increases is what is known about the minefield, what descreases is the unknown quantity. That is what QA's role is: To make an unknown quanitity a known quanitity. QA doesn't fix the defects, the cataog and catagorize them, so that an intelligent decision can be made about release and which defects are worth sending back to be fixed.
But there is a point in your message that I mus agree with, a large portion of the testing should fall on the developers. The role of QA shold not be as crash test dummies (and you shouldn't hire crash test dummies either). QA should be (a) looking at the problem from perspectives that development hasn't thought of and (b) running the more involved and incricate tests that require a full time effort, like scalability load testing and "burn in" style testing. Given that the QA folks (generally) didn't write the code they are at a disticnt advantage for (a), and (b) generally requires a different skill set than a code cowboy would use.
To think that there should be no QA or that the developers should not know it exists is like wrapping a towel around your head to get past the Ravenous Bug-Blatter Beast of Traal.