Except from some small (personal) projects or tools, is software development a team activity. The bigger the application the more people are involed, and the longer the process is. Starting with a functional analysis all the way to operations, you have many different type of people all with their own function. However, the more the functions are split up, the harder it is to keep ownership and take responsibility and more often the blame game is played. This is simply caused by the fact that it also becomes easier to make mistakes because information is passed on multiple times, and different people will interpret things differently. But even just in development, depending on how you organise the process you can easily cause people to live on their own island.
Some time ago, it was still common practice to have your development and test team separated. There still may be certain companies that hold on to this practice, and it makes sense if you do a lot of manual testing, as it would prevent your development team from doing what they do best. Moreover writing code and testing user functionality requires a different attitude. This however does not mean that the development team should not test their own code, the creation of automated (unit) tests should always be the responsibility of the development team.
There is a simple reason why this should be the case: the goal of the development team is not just to write code, it is to write functional code. To reach their goal the development team should not depend on other people. Even as a single developer you are responsible of making sure your code is readable, well tested and maintainable. As a developer you often grow attached to the code your wrote yourself, you start to care for it and it may be hard to see someone else change it too much. This is only natural because you put effort into writing it, but it is a dangerous thing and the code should be owned by the entire team, not just by the original writer.
This is quite the contradictory as the developer who designs, writes and tests the code should feel owner and responsible for it while doing so, but as soon as it is done he should let it go and pass it on to the entire team. Processes such as code review will involve the team during the transition, and pair programming goes much beyond this. Involving the entire team from the beginning is however infeasable as it will reduce efficiency way too much. To achieve the most result from your team, you want your members to be independent and take ownership and responsibility of code.
What I experienced recently was a single member who did not have access to the means to ‘test’ his code as it required access to some hardware (and the member is working abroad). This means it was on to us, the other members of the team to run the test and report back what the results were. This was as inefficient as it sounds and is a horrible work practice. This however shows another imporant aspect, people can only take responsibility if they have the tools to do so. It is absurd to make someone responsible for something they have no control over. In this case the member should not be working on this type of code.
In the end it is all about setting up a process where people can take responsibility of their work, but at the same time have a cohorent team where the members don’t mind that other people will change their code. Processes such as code review can increase this feeling as people will still be involved in all the changes, even if they are not the ones making it. The human factor can however not be ignored, and selecting people with the right attitude is crucial.