[dustingetz]

quoting Linus: "There really are only two acceptable models of development: 'think and analyze' or 'years and years of testing on thousands of machines'"[1]

i would never say that "we don't need no stinking QA", but i do believe that teams who live by "think and analyse" need QA a lot less than teams who don't.

[1] http://www.dustingetz.com/linus-think-and-analyze-motherfuck...

[dgabriel]

Actually, Linus seems to be saying: we have tested the crap out of this, and the patch broke something, and instead of playing guessing games, revert to the thoroughly tested version and think more closely about the problem before you submit stuff that hasn't been tested on thousands of machines, and will likely break one of them (because you didn't understand the whole problem). This exchange doesn't really cast any light on whether you need less QA. Instead, it seems to say: we rely on past tests to benchmark quality.

I have had my own problems with incompetent QA "engineers," but I do think an excellent QA team helps create an excellent product.

[dredmorbius]

The Linux development/QA cycle is fairly interesting.

Greg Kroah-Hartman has given a few talks on this, and from the dev perspective a lot of it boils down to "make small, discrete changes, compile, and just f*cking ship it". Testing happens among users.

But, because this is free software, there are a substantial number of systematic testers among the users, whether this is commercial distros (Red Hat, Suse, Ubuntu), noncommercial ones (Debian), organizations with a substantial interest in the quality of Linux code (IBM, Intel, AMD, from which we've got some pretty extensive test suites), proprietary software developers (who hate it when a kernel change breaks their code), independent researchers (I know there's a lot of software quality research based on Linux), and even some performance bashing by Linux haters ... which results in better Linux code.

And there are a lot of users who end up discovering bugs as well.

But the coverage is pretty good. Even if it's not explicitly rolled into the dev process itself.

Similar situations apply to other projects, though Linux for its size, scope, and user base tends to do better than many.

[jfricker]

The context of that is entirely different than a "do we need QA" context. "Think and Analyze" is an abstract philosophy, not a process for engineering.

I'd say that if you have a T&A team it would be great to measure and publish your defect rate. Of course, if you just have better than average coders, then naturally your defect rate can be low.

But even a low defect rate does not preclude having a formal QA process. Even the best coders in the world can ship the wrong product when the specifications are wrong.

[absconditus]

Linus is in no way representative of the average developer, nor are most people on HN. Most of the developers in the industry are barely competent.