Chapter 5 - The Programming Team

This continues my review of "The Psychology of Computer Programming" by Gerald M. Weinberg.

So far we've had individual programmers either working solo or in an environment where other programmers work but on separate tasks. As long as a single person can maintain the conception of the program, conflict resolution involves the thinking of a single individual, regardless how much advice is available or heeded. When a problem is too large for one person to hold in their mind at once, the scale of the problem goes up due to the increasing communication needs but is now one of a different kind. In this second case,

"conflicting technical demands are translated into potential interpersonal conflicts, and a social mechanism must be formed to resolve them"

This is part of the territory. Two people with solutions that are mutually exclusive. Programmers are proud of their intelligence and are more than willing to argue their side.

How A Team Forms

"As a rough rule, three programmers organized into a team can do only twice the work of a single programmer of the same ability"

I'm no longer as convinced of this as I once was. It really depends on how well defined the separation is between the modules.

Establishing And Accepting Goals

"Social psychologists have verified in other contexts that failure of one or more members to share the group goals affects the group performance -- not only through that member's share but through a reduced performance on the part of the others, for they invariably perceive the division within the group or the indifference of one of the members."

A non-programming example of this is when football teams get a new coach; the TV pundits like to use the phrase "They've bought into the new system" meaning that the players have taken the coaches goals for their own. A common programming example you might see in a development shop is where the current toolset and technology stack used is from Microsoft and there is that one guy who keeps muttering under his breath that "Microsoft sucks". His lack of cooperation will be felt by the rest of the team. The result may be that they avoid him instead of sharing the new trick they learned to solve some daily annoyance. No one wants to pair-program with him. The price being paid, at a minimum, is the reduced productivity of the frustrated Microsoft-hater.

The Team In Crisis

"The replacement of a leader--or any team member--is probably the most frequent and typical crisis in the life of a team. The effect of adding or removing a member depends quite sensitively on the group structure, and many a manager has been unpleasantly surprised at the change in performance resulting from the removal or addition of an 'insignificant' group member. "

If we need proof that programming is a social activity, we need look no further. Unless you are the sole programmer working at a company or on a project, there will always be a social aspect to what you do. I'll go even farther and say that unless you are the only person who will use the application, there will inevitably be people involved, from the person who asked you to write the app to the person who will be using the app.

"A member who is competent but who does not get along with the others can be an even more serious problem for the democratic group than an out-and-out incompetent. In an authoritarian group, such a member would not have much contact with others on a working basis anyway, so as long as he gets along adequately with the leader, he presents no particular problem. Indeed, some programmers prefer to work under a strong, centralized leader in order that they do not have to socialize with their fellow workers. But in a democratic team, an antisocial member cuts lines of communications and is a constant impediment to consensus in team meetings."

Sometimes we are our own worst enemy. If we want to stay our of our own way, we need to remember in software development, people are the biggest cause of failure.

Summary

Questions

For Managers:

- Are your hiring practices such that you get more uniformity on teams that you would like? When making up teams, do you try to see that a good "mix" of people is on each one, or do you strive in the opposite direction?

- Do you ever do things to try to inflate the appearance of your technical competence in front of the people who work for you? Describe some of these incidents, and also some incidents in which it was discovered that your technical competence was in at least one respect inferieor to one of the people who work for you. What were the consequences of that discovery, and do they justify attempting to cover up?

- In setting your own working goals, what part is set by what is passed down from above, and what part is set by what comes up from below? Are you satisfied with this arrangement, or would you like to alter it in some ways?


For Programmers:

- What part of programming work do you do best? Are you permitted to contribute that best part of your work to your team, and is it generally recognized that it is the best part of your work?

- Has your manager ever done anything to make you doubt his honesty? If so, describe the incident, what ultimately happened to your doubt, and how your work was affected.