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.

Task  

Name the tools of the imitative programmer.