· Which are playing their own infinite game instead?
· When are your teammates inventing together, and when they are laying down tracks to help others get to where they are? Track this carefully for five consecutive workdays, to see them move from one to the other.
View the project decisions as "moves" in a game. Imagine it as a different sort of game, crossing a swamp:
· Recall the project setup activities as a preliminary plan of assault on the swamp, one that will change as new information emerges about the characteristics of the swamp and the capabilities of the team members.
· Watch as each person contributes to detecting deep or safe spots and builds a map or walkway for other people to cross.
Reconsider the work products your team is producing:
· Who is going to read each?
· Is the work product more detailed than needed for that person, or is it not detailed enough?
· What is the smallest set of internal work products your team needs to reach the primary goal?
· What is the smallest set of final work products your team needs to produce to protect the next team?
· Notice the difference between the two. Consider running the project as two separate sub-projects:
· The first subproject produces the running software in as economic a fashion as possible.
· The second subproject, competing for key resources with the first, produces the final work products for the next team.
Think about developing a large, life-critical, mission-critical system:
· Will that project benefit more from increasing the invention and communication or from isolating the people?
· Notice which sorts of projects need more final work products as their residue and which need fewer work products.
Finally, notice the larger game within which the project resides. Notice
· The distractions on your project, such as giving demos to visitors, taking the system to trade shows, and hitting key deadlines
· How those "distractions" contribute to the larger game in play
· That moves in the larger game jeopardize your local game
· How you would balance moves in the project-delivery game against the moves in the larger game
The point of all this watching and reconsidering is to sharpen your sense of "team," "cooperative game," "moves in a game," "invention and communication," "theory building," and "sufficiency."
After watching software development for a while, reexamine the engineering activities around you:
· Identify where they too are cooperative games of invention and communication and where they are more a matter of looking up previous solutions in code books.
When you have achieved some facility at viewing the life around you as a set of games in motion, practice
· Adding discipline on your project at key places
· Reducing discipline at key places
· Declaring, "Enough! This is sufficient!"
That it is people who design software is terribly obvious ... and ignored. Weinberg's discussion of people written in 1969 was followed by a stunning silence that lasted 15 years. The silence was finally broken by DeMarco and Lister's Peopleware. Another silence followed that book. We shouldn't have to wait another 15 years before learning more about how people's characteristics affect software development.
This chapter discusses people's general "funkiness," their failure modes, their success modes, and their general mode of operation, in the following sections:
"Them's Funky People" discusses how different and unpredictable people are. A theme is that although general rules of operation may apply to this human device, any useful generalization is limited by the variations among people.
"Overcoming Failure Modes" discusses the weak points of the human device. If we are going to create systems of people working together, we should not rely on aspects of behavior that are points of failure for most people.
"Working Better in Some Ways Than Others" asks, “What is the natural mode of operation of the human device?” When we try to apply these ideas, we have to bear in mind the variations among people.
"Drawing on Success Modes" asks, “What permits us to succeed ever, given all the ways we have of failing?” The answers may surprise you for how vague they initially sound and how powerful they are in their end effect. The end of this section shows how success modes combine for a stronger effect.
The final section relates the ideas to everyday life.
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.
I found no interesting correlation in the projects that I studied between process, language or tools, and project success. I found successes and failures with all sorts of processes, languages and tools.
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.
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 non-linearly to their input. This makes them wonderful amplifiers. As the circuit being designed grows in complexity, though, that non-linearity gets in the way, and the mathematics soon become too hard to handle.
Transistors have a flat output when they are overdriven. 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 non-linear devices.