Them s Funky People


Them's Funky People

There is some resistance in our industry to the idea that people factors dominate software development.

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:

  • 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.

  • 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, 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:

  • Jenny fills in crossword puzzles starting with the first clue and going through to the end.

  • Ron fills in clues haphazardly.

  • Both get the crossword puzzle done.

  • Some programmers derive their programs mathematically (Gries, 1981).

  • Some people shuffle index cards to visualize interactions before coding (Beck 1989, Wilkinson 1995).

  • Some people design their code by looking at the textual structure.

  • As often as not, people go back and forth, up and down, and forward and backward 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.

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 stereotypical salesman. His relations with the customers were great, but he could not bring himself to write down his needs. He needed a detail-oriented aide to do the writing.

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:

  • 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 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:

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 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

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 high-level languages 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, 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.

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.



Agile Software Development. The Cooperative Game
Agile Software Development: The Cooperative Game (2nd Edition)
ISBN: 0321482751
EAN: 2147483647
Year: 2004
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net