Weinberg (1998) has a maxim, “If a programmer is indispensable, get rid of him as quickly as possible.” His contention is that a project should not be a house of cards that collapses when a single “key” person is removed.

With pair programming, the project risk associated with losing this key programmer is reduced because there are multiple people familiar with each part of the system. If a pair works together consistently, then there are two people familiar with this particular area of the program. If the pairs rotate, many people can be familiar with each part. A common informal metric (invented by Jim Coplien) is referred to as the “truck number.” “How many or few people would have to be hit by a truck (or quit) before the project is incapacitated?” The worst answer is “one.” Having knowledge dispersed across the team increases the truck number and project safety.

In a truly balanced team the hero programmer tends to dissolve themselves into the collective consciousness of the whole. It is the programmers that are in it strictly for their own personal glorification that I have a problem with. Again I go back to sports, when any athlete that views themselves higher than the rest of the team and the fact that the team could not survive without them, then this selfish ego centric personality must be contended with.

In our team we value soft skill higher than hard skills. In fact the hiring process is engineered to just that. It evaluates the candidates’ communication skills higher than that if their technical skills. Frank Layden of the Utah Jazz said it best that “You can’t teach height.” No matter how much skill you have, if you are short, you’ll be at a disadvantage on the court. You can teach someone to be a better player, but you can’t make them any taller. If a have a developer who is arrogant chances are you can’t do anything to change that. Pairing with an arrogant developer is on par with having a root canal.

I did say it wouldn’t be expository didn’t I? 