Often work assignment in traditional software projects is so that for each subsystem (or module or component) one engineer is responsible. This engineer is then also responsible for the detailled design, the implementation and also for the maintenance of this subsystem. In other words: He is the "owner" of the code; this includes all the related tasks.
At first sight this makes a lot of sense, as normally the skills and the knowledge is not evenly distributed within the team. There are experts for databases, for user interfaces, for algorithms. Or there are engineers, who are extremely talented for creating a highly sophisticated design for a subsystem.
But if you take a close look, you will notice some severe disadvantages of this approach. There is for instance the "truck" factor. This terms describes the situation about what happens whan a team member gets hit by a truck in the middle of the road. If this is the only engineer on a subsystem, then the truck factor for this subsystem is 1: the risk of loosing skills and knowledge in this area is 100%, if that person gets hit.
It is not necessary that the engineer gets hit by a truck. It is more likely, that an engineer is on vacation (especially in countries outside of US!), that the engineer is on a training, or that he is sick. In all these cases: Who will take care of the sub system the engineer was responsible for?
In practice a frequent solution is to assign a backup engineer, that is another engineer from the team, to the sub system. The objective is, that there is more than one person, who has the skills and the knowledge to work on the sub system.
Convincing at first sight, but what is the reality? Normally, there is no pair programming (at least not as the default way of creating all significant code). That means that the primary engineer works 100% of his programming time on "his" subsystem. He is the best person with regards to skills and knowledge. The backup engineer is at the same time the responsible person for a different sub system. So in reality the backup engineer works 100% of his programming time on his sub system. With this fact and under normal circumstances, the backup engineer cannot be an expert with the same skills and knowledge for both of the sub systems. You don't believe it? I have seen it in practice!
Distributing skills and knowledge as much as necessary (or possible, whatever comes first), is the best way to reduce the truck factor. XP chooses a pragmatic approach: all members of the project team are collectively responsible for all results of their work, including source code and sub systems.
Pair programming is one example of how this is achieved. This alone is not sufficient, but changing the programming partner in short time frames (several times a day if possible) is a necessary ingredience.
This does not make a beginner to become an SQL expert within a short time, but it is a sufficient measure, that this beginner can adapt as much SQL skills and knowledge, that in case of emergency he can work on the sub system with not too much negative side effects. Of course, this work would then be done using pair programming, again, probably with a different partner.
As the pairs match several times a day, the skills and knowledge will be fairly evenly distributed within the team within a short time frame. The truck factor is significantly reduced.
The are other XP practices reflecting the collective (code) ownership. The planning game is play within the team. Daily standup meetings serve the synchronization within the team.
From the programmers point of view this has the advantage, that he does not have to work all the time on the same hated sub system. Instead work becomes more interesting if one can work on different sub systems. Generally this also leads to an increase in the versatility of the programmer, as he can acquire skills and knowledge in multiple areas, making it easier when seeking new job opportunities.
© Copyright 2001-2002 by Manfred Lange, All rights reserved. Terms of use.
Last change: