Them's Funky People
As I participated in initiatives for formal program specification, advanced programming environments, and new development processes, I kept discovering that successful teams were still delivering software without using our latest energy-saving ideas.
Initially, I viewed this as a nuisance: "Why can't those people just realize how much better off they would be if they used our ideas?!"
Eventually, it went from a nuisance to a curiosity.
Slowly, it became a discovery.
I reversed my assumptions and found that the opposite correlation held: Purely people factors predict project trajectories quite well, overriding choice of process or technology.
I found no interesting correlation in the projects that I studied among process, language, or tools and project success. I found successes and failures with all sorts of processes, languages, and tools.
A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology might help or hinder them along the way).
Dave A. Thomas, founder of Object Technology International, a company with a long record of successful projects, summarized his success formula to me one day: "Some people deliver software; some don't. I hire those that have delivered."
The Quest for a Characteristic Function
If we are going to build systems out of people, we should understand people's operating characteristics.
With some trouble over the centuries, we have created mathematical models of rods, hinges, springs, resistors, capacitors, wires, transistors, and other devices. These mathematical models have served us well in constructing systems from those devices.
If the behavior of a device is complicated, engineers will often go out of their way to redesign the system so that the device needs to work only in a region of simpler behavior. Transistors, for example, produce output voltage nonlinearly to their input. This makes them wonderful amplifiers. As the circuit being designed grows in complexity, though, that nonlinearity gets in the way, and the mathematics soon become too hard to handle.
Transistors have a flat output when they are over-driven. This flat output is quite useless for amplifiers but is very handy for putting together the millions of components needed for a digital computer. The computer industry is built on the fact that transistors can be driven into two simple states. The industry would not work if designers could only work with them as nonlinear devices.
If transistors in the active region are complicated, people are more complicated still. They are not linear and not even decently nonlinear.
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 his output the next week by working 60 hours, because he isn't being distracted for those extra 20 hours. He is unlikely to double his output again by working 120 hours the next week. In fact, he is unlikely to produce even the 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:
Humans are happily contradictory.
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, and so on. 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:
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.
An individual's personality affects his ability to perform particular job assignments:
In each of these stories, it was not the process that was at fault. It was that the characteristics of the individuals 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:
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 affect 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:
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).
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 obviousright 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
Note that with the exception of compilers, tools let people make 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.
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.