If humans were linear, we could double a person's output by doubling some input. As nature has it, though, neither doubling the rewards offered, the punishment threatened, nor even the time used has a reliable double effect on a person's thinking quality, thinking speed, programming output, or motivation.
A person who works 40 hours one week might double her output the next week by working 60 hours, because she isn’t being distracted for those extra 20 hours. She is unlikely to double her output again by working 120 hours the next week. In fact, she is unlikely to produce even same work in the next 60-hour week, because fatigue sets in.
We are nowhere near creating a model of humans that is both simple and accurate enough to be used in designing a system composed of humans.
Elements of Funkiness
Humans are spontaneous, both for good and for bad. Each of the following might happen at any time on a project, sometimes with great consequences: Jenny happens to notice, at some arbitrary moment and for no discernible reason, something that needs attention and initiates an activity that helps the project recover from trouble. Ron, who always hated testing, suddenly gets the testing bug and starts regression testing his programs. Ron says something seemingly innocuous to
Jenny, and Jenny explodes in anger. Ron suddenly quits the project over a seemingly minor event. Humans are happily contradictory. Jenny is sloppy at one type of work and obsessively detail-oriented on another. Ron is communicative in one situation and close-mouthed in another. Humans are stuffed full of personality. They vary by hour, by day, by age, by culture, by temperature, by who else is in the room. Personal style and chemistry are significant matters between people.
Depending on almost anything, a person can be cooperative with one person at one moment and belligerent the next moment or with the next person. A classroom full of children can be well behaved with one teacher and rowdy with the next teacher. The same applies among project managers.
People don't work through their problems in a nice and tidy fashion:
Jenny fills in crossword puzzles starting with the first clue and going through to the back. Ron fills in clues haphazardly. Both get the crossword puzzles done. Some programmers derive their programs mathematically (Gries, 1984). Some people shuffle index cards to visualize interactions before coding (Beck 1987, Wilkinson 1995).
Some people design their code by looking at the textual structure (Beck ?). [Au: Fill in reference.] As often as not, people go back and forth, up and down, and forwards and backwards while producing a solution (Guindon 1992). Thus, legislating how a person is to solve problems invites trouble.
A person who is averse to detail-oriented work will have a hard time rechecking interface specifications for minor omissions. A concrete thinker is likely to have trouble inventing an object-oriented software framework. A noncommunicator will cause difficulty when assigned to manage a team. [will have difficulty? “will have difficulty and may cause difficulty when”
An individual's personality affects his ability to perform particular job assignments:
The cross-team manager on a large project was very concerned about being liked. He refused to make the hard decisions that the teams needed from him, and the project suffered accordingly. The best programmer was put in charge of a team of beginners. Not having the patience to tutor his people, he changed their code in the middle of the night! Although his designs were wonderful, his team neither enjoyed working with him nor learned much about programming. The person creating the program specs was a stereotypic salesman. His relations with the customers were great, but he could not bring himself to write his needs down. He needed a detail-oriented aide to do the writing.
In each of the above stories, it was not the process that was at fault. It was that the characteristics of the individual people did not fit the characteristics needed for the job role.
An individual's personal style affects the surrounding people.
Imagine the leaders of two well-functioning and stable teams:
The first is list-oriented and uses a command-and-control leadership style. The group is used to this. The second has a casual manner, gives brief instructions, and wants decisions made through discussion. The group is used to this. Now imagine that the two leaders trade places. Each team will suffer for a period, as they adapt to (or fail to adapt to) the new leadership style.
Collaboration styles vary by culture. Just as the personal styles of the key project individuals affects the collaboration patterns, so do the locally dominant cultural styles. I am indebted to Laurence Archer for contributing this example of crossing cultural style boundaries several times: Crossing Cultures
My early experience was with a consulting company in England, where the manager had to set the project up single-handedly, developing the scope, objectives, strategy, plan, etc., and then get a team together and present the project to the team.
I tried to do this as a project manager in Italy. At the team briefing the message I got was, "That is your plan; you work to it. If you want us to work together, we plan together." Powerful message.
Then I went to Australia, where the prevailing corporate culture is that the managers make all the mistakes and everyone else just does as they are told.
I set up my first project the Italian way. I called the team together in a room with clean whiteboards, described the scope and objectives, and said, "Now let's work out together how we are going to do this." The response was, "You are the manager. You work it out, and we'll just do whatever you say."
You can imagine the similar dissonance resulting from dropping a Japanese development methodology onto an Indian team (or the reverse), or from using a methodology for designing military aircraft in an e-commerce startup (or the reverse).
Inescapable Diversity
As a result of the differences between people, many technical approaches have been invented. For each fervent philosophy, its reverse is being used equally fervently somewhere else. No one approach has gained domination. Rather, each has found support with a sympathetic programmer and has grown in use as the programming population has increased. Just as the number of ways of creating software will probably continue to grow, the differing approaches will become stable as they find their support clusters.
This all seems obvious—right up to the moment of applying it on a particular project. People have a tendency to forget it, though, as they prescribe software-development methodologies for a project and announce the "correct" way of working. Worse, they often expect everyone on the project to work using that one approach.
It is good to have variety on your team: abstract and concrete thinkers, orderly and random approaches, with some people who enjoy diving into the innards of a system and others who enjoy designing the user interface, documenting the system structure, or selling the final product. Having people with different characteristics on your team allows individuals to work in areas in which they are strong. The same diversity that presents communication difficulty and personality friction also allows for efficiency, so that mixed teams often outperform homogeneous teams (Sully 1998).
People being different does not mean that all general statements about humans are false. Some things that we can say are valid in a broad sense and vary primarily by degree and population. We will build upon such statements, even while accepting that people differ.
What we can't do, however, is expect people to be either predictable or the same as each other.
The Place of Technology
Technology increases effectiveness under any of these four circumstances:
· When it lets people express their thoughts more easily. High-level languages let people express ideas more succinctly. Some let a person think in a technology space that is closer to the problem space, reducing interfering thoughts about implementation constraints.
· When it performs tasks that can't be done manually. Measuring and profiling tools gather data that otherwise can't be gathered. They are cited by programmers as essential tools to have.
· When it automates tedious or error-prone activities. Compilers, spreadsheets, and software configuration management tools are so basic that some people don't even refer to them as tools but simply assume their presence.
· When it facilitates communication across people. In the world of distributed software development, all kinds of communication tools help the team.
Note that with the exception of compilers, the tools let people make the decisions. The tools provide feedback and let the people consider the result.
In the case of compilers, people complained for decades that the compiler could not allocate registers and sequence instructions as well as people could. As it eventually became clear that the compiler could do that, people forgot about register allocation and moved their thoughts closer to the problem space, working on algorithms and program structure.
Technology does not increase effectiveness to the extent that it works against the grain of human cultural values and human cognition. Consultants not Trading Notes
A consulting firm, wanting to leverage its consultants' technical experience, installed Lotus Notes and encouraged the consultants to trade technical notes and help each other.
They forgot that consultants retain their competitive value by owning secrets. To those consultants, knowledge was not just power, it was income.
The Notes database stayed mysteriously empty, despite constant exhortations from upper management for the people to share their secrets.
Conflicting Generalizations
As you proceed through the next sections, please bear in mind that when talking about people, seemingly conflicting ideas come into play at the same time.
People do vary, and it is possible to make a few broad generalizations, and there will be exceptions to those generalizations.
This section discussed the idea of the exceptions. Now let's take a look at some of the generalizations.
Trygve Reenskaug cautioned me about discussing human failure modes. "If you give a dog a bad name," he reminded me of the old saying, "you might as well hang him." The hazard is that some people will use my naming of failure modes as excuses for poor work. Trygve reminded me that often what passes as a human failure has more to do with the working environment, as discussed in the last section and illustrated in this story he told me: The Small-Goods Shop
There was a small-goods and buttons shop nearby that was always in a terrible shape. The place was a mess, and the girls were either doing their nails or on the phone and didn't have much time for the customers.
That business closed, and another small-goods and buttons shop opened in its place. This place was wonderful! It was clean, tidy, and the girls were attentive to their customers. The only thing was ... it was the same two girls!
C3 Culture Shifts