Maybe you all know the following issue from your own software project: Someone of your project team gets sick, leaving the team or cannot work for the team l for other reasons. And suddenly you get big problems because no one can take that person’s work. He had a knowledge monopole for his software module. And now you will lose a lot of time because someone of your team must analyze the actual source code, status of implementation, the fulfilled and open requirements of the module.

Of course, there existing some well-known practices to avoid such situations. For example the extreme programming approach defines some interesting practices. So that could be a solution. But in reality it isn’t that easy. You cannot simply switch to extreme programming and hope that all issues are gone. There are also some disadvantages if you use extreme programming practices like pair programming. They may be expensive. For example in pair programming you will use two developers to solve a problem instead of one. In an easy calculation, the implementation of the module will become twice as expensive. On the other hand you will get benefits like shared knowledge and higher code quality. So the benefits may amortize the higher costs. But this depends on you type of project and your goals.

What if you are happy with your current development process and you only want to share the knowledge a little more between the project members? I think an easy solution is to define the module responsibilities independent from the implementation responsibilities. So I like to have a person which is responsible for a module. This might sound wrong to you in the first moment because principles like extreme programming want to share knowledge in the whole team and so they want to avoid module responsibility. But this is an expensive goal and also requires an experienced team.

So even if it sounds like a contradiction, I like to have defined module responsibilities. So each software module should have a defined team member which is responsible for the module. But “responsible” does not mean he is the developer, owner or decision maker. It means he is more a contact person or consultant. Each of the team members has his own strengths and experiences. So the module responsibility should be assigned with respect to these competencies. For example if you a have a database expert in your team, he should become the responsibility for the module which does the data serialization with a database. But it does not mean that he will implement the whole module or that he will do all design decisions. Important decisions should be done in the whole team and implementation should also be done by different people.

At the end the person responsible for the module has the best knowledge about the module. So if this person is no longer available for your team you will also lose some knowledge and you need time to compensate this loss. But your whole team together also knows a lot of details about the affected module. You have a swarm knowledge which you can use. The deliberate separation between responsibility and implementation will result in a shared knowledge. Furthermore you use the experiences of the team member because they are explicitly defined as contact person and consultant.

Depending on the size and duration of your project you may also define a representative for each module. So you have two people who are responsible for the module. On is the main person and the other one the representative. They have to share their knowledge and do important decisions together. So the representative may not know each detail about the module but at the end he should have the important 80% of the main owner’s knowledge about the module. So you can compensate temporary or permanent absence of the team member responsible