Lately, we have been discussing in class why software development can become a complete disaster and result in a "big ball of mud" (unstructured, complex codes). The reasons can be multiple: management (too close or too lose), the wrong team, the wrong process but also the wrong attitude. 

In order to work together on successful software development, every member of the team needs to work towards the same goal, giving the best he can and supporting his/her team members. 

One pattern that appeared in the article "they write the right stuff" (Fishman, 2007) was the notion of healthy rivalry. The software development team is seperated into two teams: those who create the codes and those who test and verify the codes. The fact that the teams worked against each other in terms of quality assurance but were aligned to work towards a common goal (developing the best software) made this process particularly successful. The code creators, knowing their code would undergo critical assessment and quality tests, would put more efforts in pre-testing their own codes and delivering better results to that the opposite team had fewer mistakes to reveal. On the other hand, the verifiers, trying to reveal all mistakes in the code, were twisting the codes upside down to find all possible mistakes and "beat" the other team. However, is mistakes were made in the end, no individual scapegoating or blaming would be allowed as their created and verified the codes in group. If there was a mistake, the process and system allowed the mistake to occur, so everybody was responsible.

But it is not just about the process. It is very difficult to find the right people that would feel comfortable in such a setting: being controlled, work as a team, no individual blaming but of course in return also no individual rewarding was possible. This is particularly interesting as many people mistakenly believe that "IT staff" and developers do need to have team spirit, communication skills and leadership responsibility. But in fact, this example shows that this self-directed and auto-sustaining process of creation and correction requires these skills and capacities from the team.
This is just another great example of management myths in software development.