Two groups, within engineering, that are sometimes seen as having conflicting goals are development and QA. In the most dysfunctional organizations development does nothing but write new code and "throw it over the wall" to QA who acts as the gatekeeper to make sure it doesn't go out with too many bugs. Development sees QA as the barrier they must get over (or around) in order to get "their" code shipped. And QA sees development as a bunch of cowboys who would ship just about anything that compiles if it weren't for QA holding the key to the gate. A cycle is set up in which development says, "here's some code; we've done our job", and after some time QA says, "No, you haven't, try again." Because QA is the gatekeeper, they feel—probably correctly—that they are ultimately responsible for the quality of the code that goes out the door. But QA can't actually affect the quality of the code: they can detect that it lacks quality and send it back or they can let it out into the world. If it ships with bugs, those bugs are now their fault. But because almost no software is absolutely free of bugs, as soon as the software ships QA has failed. It's not surprising that developers begin to feel that QA is more interested in stopping the code from shipping than anything else. And once developers feel that way, they stop caring about bugs that are reported back from QA—of course QA is reporting bugs back to development, they think, that's all they ever do.
Of course software companies have to ship software to stay in business so eventually management overrides QA's gatekeeper role and decree that the software will ship. QA, set up for failure from the beginning, is further embittered and resolves that next time they'll stick to their guns and not let the software ship until all the bugs have been fixed. Or the QA group itself, knowing that the software can't ship until they "validate" it and knowing that the software has to ship or the company is sunk, eases up in their testing, settling for easier tests that "show" the software works, rather than the hard tests that will show it doesn't.
Of course most organizations aren't quite that dysfunctional. Developers take pride in their work and want to produce bug-free code. And QA engineers sincerely want to help the company ship good software. But the dynamic is still frequently set up in the same pattern as in the worst-case scenario described above. Instead of counting on people's better nature to overcome a broken dynamic, we should set up a functional, congruent relationship between QA and development.
The key is to remember that the development and QA organizations have the same goal: to ship great software. What should differ is the way they approach the goal.
Writing software is an extremely difficult task. Like batters in the major leagues, even the best programmers fail more often than they succeed. The analogy hints at the attitude the developer should take toward their work. Like a batter, a developer wants to get a hit every at bat. They should do everything in their power to succeed: concentrate, keep their eye on the ball, use good technique, practice regularly. But we are all fallible and the ball is moving pretty fast: there's no great shame in striking out as long as you pick up your glove and hustle out on the field for D and cheer for your teammates when it's their turn at the plate.
Less metaphorically, developers must try to not write bugs yet still recognize that there are almost certainly bugs left in the software after they have done their honest best. Those bugs are both their fault and not their fault. They are the developer's fault because who else's fault could they be? But they are not the developers fault because nobody is perfect.
That's where the QA group should come in. If we all want to ship bug-free software and we believe that the software always has bugs left in it after the developers have done their part, then our only hope is to have a group of engineers whose goal is to find those bugs. Note there is a subtle but crucial distinction between "verifying that the software is bug free" and "finding bugs". The former is, in fact, impossible for anything more complex than a few-line program. And it is, as Glenford Myers points out in his classic, The Art of Software Testing, demoralizing: if your job is to verify that the software is bug free, every time you find a bug you have failed. But if your job is to find bugs, every bug you find is a victory.
Recognizing that software is bound to have bugs in it and giving QA the task of finding as many as possible also sets up a much healthier relationship between development and QA. When QA finds a bug they have succeeded and it doesn't mean that development has failed—it means that even the best hitters sometimes strike out. Or, to reverse our analogy, even Cy Young winners sometimes give up a hit. The proper attitude of a developer towards a QA engineer who has found a bug in their code is that of a pitcher toward their centerfielder who has made a leaping catch at the wall to pull down a ball otherwise heading into the stands.
Finally, since QA and development are on the same team, the decision to ship isn't distorted by putting one group or the other in a position where they have failed as soon as the software ships. Development wins their game by putting in features and taking out bugs that made it into previous releases despite everybody's best efforts. And QA wins every time they find a bug and get it fixed before a customer ever sees it. Of course there will, and should, be some friendly rivalry between development and QA. Developers should try to frustrate the QA engineers by producing code that's so good they can't find any bugs in it. And the QA folks should be out to prove that they can find bugs in any software. Chances are, both sides will have some successes and some failures. Some days you win with hitting; some days your pitcher gives you a shutout in a 1-0 game.
One last advantage of this division of labor is that management doesn't get to hide behind QA anymore, when making the decision to ship. If the end of the quarter is approaching and the company needs to book revenue and QA is still finding bugs at a ferocious clip, management has a hard decision to make. But at least management knows that QA, having not been demotivated by pressure, implicit or explicit, to "validate" the software, will not ease up their testing and will find as many bugs as they can in the time remaining. And development, no longer wasting time trying to convince QA to "let the software out", can instead devote their effort to fixing as many of the bugs as they can before the software has to go out the door.