The Bozo Effect

The Bozo Effect

One important factor of team work is whether the team has jelled. This refers to when the members of the team work so well together, they are more than the sum of their parts . In other words, their output is greater than they could have achieved individually, added up.

Whether a team jells is often a function of individual attitudes; specifically , of egos. It is true that programmers need egos. They probably need a big one to maintain an attitude of perfection while solving difficult problems. However, they must find a way to submerge their egos in forming a team or the team will never jell. We have observed the effects of this in action. We refer to effectiveness of teams relative to egos as the Bozo Effect.

Bozo was a clown character. Sometimes, people who disrupt teams are referred to as Bozos. The Bozo Effect is a function of how many Bozos can be part of the team and still have it deliver reasonably working software.

Our observation, not surprisingly, is that smaller teams, up to four people, can be totally disrupted by a single Bozo. This is usually a person who leads with ego, and refuses to adhere to the decisions of the group in case of disagreement . Eventually, the tension is so great that the team will self-destruct.

Conversely, a larger team can handle more Bozos. We have observed that up to three Bozos can be part of a team of eight and it will still deliver. This is probably because a majority of the team is still productive. The Bozos are drowned out, and clients are used to late software, unfortunately .

This legislates against the wrong type of star performers. Another of our observations, this time of many hundreds of student programmers, is that less than 1 percent are intuitive programmers, and the rest are imitative programmers. The difference is that the intuitive programmers can code from the solution that seems to be already in their heads. This solution will normally be the correct one, but when you ask intuitive programmers how they arrived at a solution, they are as mystified as you are. Imitative programmers are reflection in practice adherents (see Chapter 10, Learning Processes in Software Engineering ). When they observe an aspect of a problem, they might think, a loop worked here that time I had a similar problem. They often do not invent solutions; they copy them from past experience.

We deduce that having larger numbers of imitative programmers is not a bad thing. In fact, it seems simpler for imitative programmers to reduce the effects of their egos. Moreover, intuitive programmers tend to not make sufficient documentation. However, intuitive programmers seem to do better on programming tests, and upper management often searches for them, ignoring their shortcomings, because they can be more productive in a shorter period of time.


Name the tools of the imitative programmer.

Mind the Gap

Anyone who has ridden on an English train has seen this inexplicable phrase on a sign near an exit door. It means there is a gap between the train and the station s platform. Do not fall in it. There is also a major gap between the best and worst programmers. This gap, if not minded, may make it difficult or impossible to successfully populate a democratic team.

A gap this large is historically quite possible. For example, the best fighter pilots have great shoot-down rates. Others fly every day and shoot down nothing. One German on the Eastern Front during World War II brought down over 350 Soviet airplanes. How was he so productive? He had a process: he flew closer and closer to the enemy s rear until one burst from his guns would make the other airplane explode. In fact, several times, debris from these close explosions brought down his own airplane. Still, comparing this pilot to the nonproductive ones reveals a prodigious gap.

The gap between the best and worst programmer is smaller. There are habits that can close this gap. A devotion to documentation is one. With adequate explanations , a project can be passed on. Those at the top of the heap as programmers rarely have that habit.

Balance is crucial here. If the project is short lived and a one-time job, then using star programmers is generally all right. However, if the source code will be maintained and used for years , programmers of lesser ability, even though slower as developers, are more likely to ensure that the project can move forward.