Having worked in similar environments in the early 90's on desktop software, there are some serious downsides to this approach. Basically, it can lead to havin

Having worked in similar environments in the early 90's on desktop software, there are some serious downsides to this approach. Basically, it can lead to having a rift between developers and QA, and in a big corporation, it can become a bureaucratic mess and a 'us' vs. 'them' attitude between groups. I've been in long heated meetings between QA and Dev arguing over individual bugs, not so much on behalf of the customer as opposed to face-saving exercise. From the article: "And the things they did to software went beyond all bounds of rational use testing and were more akin to software torture." In a perfect world with unlimited time, it's great to find bugs through contortions but usually there is some costs associated with it either with QA not focused on other areas that matter, or having a developer focused on confirming that bug as opposed to working on something else. Sometimes it's great in a bigger organization to have a unique culture so I agree with the jist of the article and to other HN comments. For instance, I worked at a company on a smaller Macintosh team that fostered a healthy competition with the much bigger Windows team which worked well. I'm just not so sure it works well when people are essentially working on the same project where interfacing with each other is a requirement.