Working Better in Some Ways Than Others

Reminding ourselves that people vary, that certain broad generalizations hold, and that there are exceptions to each generalization, let's look at some of people's natural ways of working.

People generally work better by starting with something concrete and tangible, such as examples, by altering rather than creating from scratch, by watching, and by getting feedback.

One of my favorite sentences comes from Wenger and Lave (1993) about the power of the concrete:

"The world carries its own structure, so that specificity always implies generality (and in this sense, generality is not to be assimilated to abstractness). That is why stories can be so powerful in conveying ideas, often more so than an articulation of the idea itself."

Concrete

Cognitive research provides support for the idea that our minds operate directly from concrete examples (an idea that is remarkably in harmony with the properties of neural networks).

Johnson-Laird and Byrne (1991) suggest that people perform logical deduction by imagining concrete situations and concrete counterexamples rather than from manipulating predicate calculus in their heads. For example, in a problem about billiard balls, "it is possible to frame rules that capture [the] inference, but it seems likely that people will make it by imagining the layout of the balls."

They suggest that in performing deduction, we

1. Construct an internal model of the state of affairs that the premises describe.

2. Formulate a brief description of the models constructedone that ideally asserts something not explicitly stated in the premises.

3. Search for alternative models of the premises in which the putative conclusion is false.

Notice that even the third step, the validation step, involves constructing concrete examples.

Robert Glass (1995, p. 178) relates a remarkably similar version of the software design process. Citing other researchers, he relates that people do the following when composing plans:

1. Build a mental model of a proposed solution to the problem.

2. Mentally execute the model to see if it does indeed solve the problem, providing sample input to the model to see if it produces correct output.

3. When sufficient sample inputs have passed the test, assume the model to be a suitable design model and begin representation of the design.

If people really do make use of concrete situations in their thinking, we should find such artifacts among programmers' work products. User composites and interaction diagrams are two such artifacts.

In the user composites technique, the development team creates a composite sketch of one or more fictitious users of the system. Ideally, they invent several: one user who is lazy, one who is fanatically detail-oriented, one who is an expert in all the shortcuts, another who is slow to learn, and so on. They make these composite sketches as concrete and real as possible, even giving the imaginary people names. By putting very concrete images of future users in front of the design team, the team can more easily imagine how each would react differently to the system and can create system capabilities suited to those different sorts of people.

Interaction diagrams (of which there are two forms, collaboration diagrams and sequence charts) tell the story of objects interacting over time. They are created by drawing object instances on the page and drawing arrows showing the messages between them. In collaboration diagrams, the objects are placed anywhere on the page, and the arrows are drawn between them and numbered to show the time sequencing of the messages. In sequence charts, the objects are all placed as column heads at the top of the page. The interactions are shown going down the page as arrows from one column to the next.

Of the two, sequence charts are a recommended part of many OO design techniques. Collaboration diagrams, which are mathematically isomorphic to sequence charts, are so rarely mentioned in methodology texts that it was only after several years of teaching and coaching that I noticed that beginners often showed me their discussion results in collaboration diagrams, not sequence charts or class diagrams.

I suspect the reason that collaboration diagrams are not mentioned in methodologies is that they are temporary artifacts. They are useful in creating designs and in communicating about specific situations, but they are not preserved in the heavily distilled design documentation the project team feels obliged to produce.

As we become better at preserving records of transient discussions, I expect to see such diagrams used more in design and documentation.

Tangible

Beyond concrete is providing something tangible, something that people can touch.

Pelle Ehn used paper prototypes in the mid-1980s, helping a typesetters union discover how computer systems might help them. He used cardboard boxes and bits of paper to represent the computer screen and its contents, to understand how the as-yet-unimagined system might work. The people worked through their daily operations to discover ways in which a computer might be useful. They felt comfortable manipulating these tangible, movable, and unfinished-looking props. Paper-based user-interface prototypes have grown to be a favorite of professional user-interface designers (Hohmann, 1997).

During the early, discovery phases of designing a user interface, such "low-fidelity" prototypes are considered even more effective than the screens simulated with care on a live computer screen. They are not only tangible but almost invite a person to change them.

Rough Architecture Drawings

An architect designing a hospital told me that he never shows the customers a computer-drawn plan of the building. The customers view it as too far along to change, no matter what he says.

He therefore always draws the plan in pencil so that they feel comfortable drawing over it.

An extension of the low-fidelity mock-up technique is one called informance (Burns 1994). An informance is an interactive performance, showing the not-yet-built system in use in its predicted future setting, using a mock-up so concrete that people can interact with it. Informance allows trial users to live the life of the future user in a realistic future environment.

One reported informance showed a hair stylist using a proposed system while cutting hair. In another, the group built a walk-through apartment in which actors playing patients used computers to talk with each other and build community while staying in bed.

By making the informance setting concrete, everyone involved in development can see the strong and weak points of the proposed idea.

A popular design technique that takes advantage of tangibility is the Class-Responsibility-Collaborator (CRC) card technique mentioned earlier. In this technique, an index card is put on a table to represent a specific instance of an object nominated for use in a design. The designer picks the card up and moves it around, at the same time discussing its behavior with respect to the other cards on the table.

CRC cards are concrete and tangible examples that let designers work multi-modally through concrete situations. People consistently report that moving the cards online reduces their effectiveness.

There is something about picking up a couple of cards and saying, "This object sends . . . this other object . . . the request to do XYZ . . . No, that's not right; let's try another one . . ." that triggers an emotional, physical response about the quality of the design.

Something to Alter

Copying and altering previous work is a standard mode of operation used almost daily by people in all fields.

Faced with starting a new letter, invoice, proposal, document, program, or project plan, a person finds a previously done sample, copies it to a new work area, and changes all the particulars until the work product becomes what the needs. A cook will copy a recipe and vary just one part. A project manager takes over the previous project's plan and changes the line items to reflect the current project. A requirements document or database schema gets similarly copied and altered. Children (and adults) learn hypercard programming by copying someone else's program and guessing at the simple things to change.

The TalkingParrot Program

My first Smalltalk program was a direct-manipulation editor for sequence charts.

Not yet knowing Smalltalk, I copied the TalkingParrot example from the Smalltalk tutorial and then changed every line in the program until I got my editor. Nothing was left of the original TalkingParrot except its use of the sophisticated Model-View-Controller (MVC) architecture (which I had never heard of, at the time).

A year later, my colleagues were having trouble changing their program to accept input from the network instead of from the keyboard, and I wasn't. It turned out that the MVC architecture I had inadvertently picked up from TalkingParrot was what was making my life so easy.

This copy-alter technique has been applied even to completed applications.

Airline companies traded frequent-flyer applications in the late 1990s. A frequent-flyer application, by itself, provides little competitive advantage to an airline company. So one company would recover development costs by selling its frequent-flyer application to its competitor. The buyer received a graphical model that generated application code that would need tuning, and the actual, generated, and tuned code from the previous company. The buyer recognized that the application would not be quite correct but that it would take less effort to alter it than to build it from scratch.

Glass (1995, p. 182) tells that a first design model

"may very well be a reused model rather than one created by the designer in response to this particular problem. Visser (1987) discovered that, for problems encountered before, designers employ an 'example program' as their starting point, and then observed, 'Designers rarely start from scratch.'"

You can and should start taking advantage of people's strengths in copying and altering work samples. Create a small, online library of real samples for work products produced on your (or some previous) project. Other people can then simply copy one of the samples as the base for their own work. In copying it, they will pick up both the structure and style from the sample, while changing the details to fit their purpose.

The implication is, of course, that you would like the work samples you collect to be relatively "good," having structure and style you don't mind having copied. They don't have to be perfect, of course, just "good enough."

One book already does this. Developing Object-Oriented Software: An Experience-Based Approach (IBM OOTC 1997) is a collection of work product samples used by IBM's OOTC on various projects during the mid-1990s. The OOTC avoided fighting over methodology by providing examples of various work products and letting each project team choose the examples they felt compelled to use.

You may notice that many of the foregoing stories use surprising low-tech items, with much use of paper and cardboard. O'Dell (1998) wrote about the World Bank's successful knowledge management and transfer experiences with an appropriate lesson:

"For best results, take one spoon of low-tech and one spoon of high-tech. Mix and drink."

Watching and Listening

Humans have a knack for learning by watching as well as by doing.

Wenger and Lave (1993) discuss success and failure in apprenticeship-based professions. They highlight the value of line-of-sight and line-of-hearing learning in these professions. After I read the book, I made the following unhappy discovery:

Line-of-Sight Design Learning

As I walked into our programmers' room, I saw all the programmers staring at their own screens! There was no line-of-sight learning anywhere in the room.

I had the chance to change the situation somewhat a few weeks later. When someone asked a design question, I made sure we discussed it at the whiteboard or said our ideas out loud.

It took another month or two, but eventually I could hear the designers talking about their designs using the words and ideas we had been building up in the room over the previous month.

This room setup is the basis for the "Expert in Earshot" strategy (Cockburn 2000a), which is further developed in "Convection Currents of Information" on page 107.

Programming in pairs is a programming technique that provides line-of-sight-and-hearing learning. Larry Constantine (1995) found this technique so effective that he nicknamed Brian Kernighan's use of pair programming "dynamic duo" teams. Pair programming has been repopularized largely through Extreme Programming (Beck 2000). Groups who practice pair programming report faster learning of both programming techniques and problem domain, as well as faster code production and lower defect rates (Cockburn 2001b).

Supporting Concentration and Communication

Software development as both a thinking-intensive and communication-intensive activity presents an interesting dichotomy.

Programmers need sufficient quiet time to get into a quiet and productive mode known as flow (Csikszentmihalyi 1991). After spending 20 minutes getting into a state of flow, it takes only a minute or two of other conversation to disrupt it.

Every project team should find a way to provide quiet times sufficient to get into flow and should protect those times. DeMarco and Lister (1999) suggest designating two hours as quiet time every day, turning off all phones and banning all meetings during this time. I watched one organization adopt this convention. It was so appreciated, from the CEO on down, that among three dozen suggestions for improvements to the company's working habits this was uniformly acclaimed as the most critical.

XP recommends a "caves and common" room layout (Auer 2002). The center of the room is used for group work: tables with two to six workstations and space for two people at each workstation (see Figure 3-13).

The outside of the room is set up with individual areas where people put their bags, make phone calls, answer e-mail messages, and so on. With this layout, the people have close access to other people while they are designing and private space for their personal needs.

I have found no consensus on the question of private offices versus shared workspace. People regularly tell me that they have produced their best work when they shared an office with someone else on the project or worked in war-room seating. Some say that they enjoyed the quiet of their private offices but produced better work when they didn't have a private office. Others, however, are so strongly attached to their private offices that they would quit rather than move into a shared workspace. That may be too high a price to pay for communication.

Personality-Matched Work Assignments

For people to perform as well as they can, it helps if their job assignments are aligned with the strong points of their personalities, not their weak points. Methodologies name the roles that must be present on a project but don't mention the personality characteristics required for each role.

Here are three examples of a person whose personality characteristics did not match those required for the role:

The Socially Minded Manager

Once, on a large multiteam project, the cross-team manager was socially minded to the extent that he did not want to offend anyone.

As a result, he would not make those hard personal and priority decisions that are exactly what the cross-team manager is hired to make.

The Nonverbal Team Lead

The person hired as lead programmer and mentor was a stereotypical noncommunicating programmer.

Rather than coach the novice programmers on improving their programming skills, he simply changed their code when they weren't around!

The Concrete-Thinking OO Designer

One person on our OO project desperately wanted to learn object-oriented programming. He seemed unable to get his thinking to an abstract enough level to generate good OO designs, though.

After much coaching for six months, his programs still looked like the user interface or the relational database.

What could be done with these people instead? On the first project, the person was too high on the project ladder to be replaced, and so the project continued to suffer. On the second project, the person was eventually replaced with someone who had good communication skills, who taught the novice programmers basic OO design skills.

On the third project, we were luckier. The person was spectacularly good at defining requirements, where his careful thinking and attention to detail paid off. In exchange for his working on the requirements, he continued doing OO design and programming on sections of the system where the quality of the design was not a critical issue. Everyone benefited: He had fun doing the programming, and the project was safer due to the high quality of his requirements work.

Talent

The best programmers on the team may be so much better than the rest that just a few of the best programmers can put out more than all the rest combined.

eBucks.com Goes Live

Vincent Coetzee, CTO at eBucks.com, told of how their group got the company's new eBucks system out in just three months.

The best two programmers programmed most of it.

I nodded as I heard this. "The old solution. Get the best two programmers to sit together and program it up rather than coordinate 20 people through a fancy methodology."

But that left an open question. I knew that he had many other duties and would have to attend so many meetings that he couldn't possibly concentrate enough to program. I asked him about that.

He answered, "I attended meetings until 5 p.m. or so and then wrote code from 6 p.m. until 2 a.m. each day."

Oh. Another far-too-obvious solution. Have the two best people work back-breaking hours for several months.

Painful, but effective.

This combination of talent and practiced skill I call personal prowess. Although a manager can increase the skill of the team members by encouraging them to learn and sending them to courses, he can't change the talent level of the team. A talented designer will still outperform an average designer with good skills.

John Wooden, the famously successful college basketball coach, considers talent such a key issue that he labeled his first coaching secret "Secret #1: The team with the best players almost always wins" (Hill 2001, p. 63).

Rewards That Preserve Joy

Inventing reward structures is tricky. I recently got tripped up on this myself, in what I thought was a simple work-reward situation:

Picking Dandelions

Dandelions were beginning to clutter our backyard. Having three children aged 10 and under, I concocted a brilliant solution: I offered them one cent per yellow flower and ten cents for any dandelion in the seeding stage. For five to ten dollars a year, I thought, we'd get rid of dandelions in a few years.

The kids brought in bags of dandelions, and I paid out the cash.

On the third year, I commented to my now-12-year-old, Cameron, that it looked like we had more dandelions than the previous year.

He said, "Sure. Last year I ran around, dancing and waving all the white dandelions around. When Sean asked why I wasn't just putting them into the bag, I said, 'I'm planting money for next year!'"

If I had that much trouble with that simple situation, how much harder is it to find an appropriate reward for creating software? Should you reward

• Lines of code sent to the test department?

• Low defect rates delivered to the test department?

• Function points delivered each month?

• The number of lines reused from a corporate library?

In a Dilbert cartoon, the manager offers rewards related to the number of program bugs discovered. A programmer immediately announces: "I'm writing myself a minivan this afternoon!" (How like the dandelions!)

Even if you can name an appropriate reward structure, what does the organization actually reward? Is it aligned with what is most important for the company?

Lines-of-Code-Based Pay

A large company I dare not name ran an initiative to encourage reuse. Programmers' performance, however, was evaluated based on the number of lines of code sent to the test department each month.

One person I knew incorporated components from the company's reuse library, as encouraged. She was, however, only given credit for the lines she wrote herself, not those she reused. As a result, she received a low evaluation for her programming performance.

Programmers detect the mismatch and sometimes find subtle ways in which to retaliate.

Goldplating

A team leader in a small start-up company complained to me that one of the programmers was adding unnecessary complexity to his design"goldplating" itto make it more "interesting" for himself.

When we looked at the matter together, we saw that this person was earning a small, fixed salary in a high-risk position in a start-up company. His risk exposure for working there was high, his reward low.

He had evidently made his own self-reward scheme, inventing "cool" code that either would make his daily life interesting or would enhance his employability for his next job.

This sort of mismatch leads to programmers behaving in ways that hurt the company, just as Cameron's "investment" view of dandelion picking hurt my plans for the backyard.

One person wrote to me that he feels stock options are a form of reward that aligns the good of the company with the programmer's behavior. He wrote that he is now working in maintenance, not because it is more fun but because it is the best way to protect his stock ownership in the company.

Reward schemes are an even more slippery subject than I have implied so far, though. Alfie Kohn (1999) writes that rewards actually reduce the intrinsic joy and output quality of an otherwise fun activity:

"Young children who are rewarded for drawing are less likely to draw on their own than are children who draw just for the fun of it. Teenagers offered rewards for playing word games enjoy the games less and do not do as well as those who play with no rewards. Employees who are praised for meeting a manager's expectations suffer a drop in motivation. . . . In one study, girls in the fifth and sixth grades tutored younger children much less effectively if they were promised free movie tickets for teaching well. The study, by James Gabarino, now president of Chicago's Erikson Institute for Advanced Studies in Child Development, showed that tutors working for the reward took longer to communicate ideas, got frustrated more easily, and did a poorer job in the end than those who were not rewarded."

If rewarding intrinsically motivated behavior destroys intrinsic motivation, what rewards might retain a person's intrinsic motivation?

• Pride-in-work

• Pride-in-accomplishment

• Pride-in-contribution

Pride-in-Work

Pride-in-work is exemplified by an ad for Scotch whiskey that I saw some years ago (sorry, it was long enough ago that I have to paraphrase this example). The ad ran something like this: "If you want a set of hand-carved golf clubs from Ian McGregor, you'll have to wait two years. There are three people ahead of you. (Good things take time.)"

The ad made it clear that Ian McGregor took pride in his work, and as a result, he did an outstanding job (as did the Scotch distillery, by extension). The clientele could tell the difference and were willing to wait.

I only recently became aware of the possible role that pride-in-work might play on a project, but it wasn't long before I heard a programmer say this:

"Well, the system's OK . . . I mean it functions, but I can't really take any pride in my work. I'd like to go home feeling good about my program, but I don't. It's just a big mess that barely works."

He continued by saying that he wasn't really happy with his job, even though things were "working."

Pride-in-Accomplishment

Winning is a great reward. We create a "small win," a powerful motivator, whenever we complete something (Weick 2001).

In software, we create an early win by delivering running, tested, useful code quickly. Using the principle of small wins as a motivating reward, a team delivers as early as possible the smallest thing that will count as a win for the team. That early delivery demonstrates to both the sponsor and the team that the team can work together and deliver. It boosts the morale of both.

To keep with Weick's principle of small wins, the team will then deliver more running, tested, useful function at regular intervals. This is the "Early and Regular Delivery" strategy underlying incremental delivery, described in Surviving Object-Oriented Software (Cockburn 1998).

One question that arises with Early and Regular Delivery is what to deliver first. On the one hand, it seems a good idea to leave the hardest thing until the end so that the team knows everything possible about the system before attacking the hardest problem. This is the "hardest-last" strategy. It has a surprisingly bad track record, because many projects simply can't be done by the people assigned. Continually deferring the hardest part to the end, the project schedule does not become more reliable over time but stays unstable until the last piece of design magic is found . . . or the sponsors run out of money.

The opposite strategy is to get the hardest part out of the way, using a "worst-things-first" strategy. This is better, but it has a weakness in that if the team cannot solve the hardest problem right away, no one knows what is wrong: Is the problem too hard? Is the team wrong? Is the process wrong? Are the tools wrong?

The repaired strategy is "simplest first, worst second." By constructing a "walking skeleton," a barely connected version of the system that can handle just one small type of action, the team learns how to work together and gains an early win.

With one victory under its collective belt, the team is in a stronger position to attack the worst problem. If the team can succeed with this, it once again gains doubly: The hardest part of the project is over (stabilizing the project plan), and the team accomplishes a major win.

If the team is not yet strong enough to attack the worst problem, team members attack the hardest problem they are sure they can solve. This gives them more practice on their assignment, a bigger win for their morale, and greater confidence in their ability to attack the hardest problem. They continue in this way until they solve the hardest problem, and the project starts to become easier.

Pride-in-Contribution

The third possible intrinsic reward is pride-in-contribution. People's desire to contribute is so strong that I regularly see programmers damage their health and private lives in their effort to contribute to the team.

Here is a story of a key developer who changed his attitude toward the project when it was made clear to him what his contribution to the project and the community meant.

Realigning Commitment

The programmer was a senior-level contract programmer who was working on the most complicated and critical portion of the system. He was already being paid well.

The executive involved was a socially astute person.

At some point, the executive had a conversation with the programmer. The executive made it clear how important this particular programmer was to the success of the entire corporation, and he did it in a way that illustrated to the programmer that building a really clever, beautiful, and perfect solution that was hard for the other people to use would be to the detriment of the entire community and that the programmer could make a very positive contribution to everyone involved by making a simple and workable solution, even if it was less aesthetic or less mathematically sound.

Almost immediately, the programmer shifted his behavior. Rather than sneer at the company and the technology, he became interested in delivering value, contributing to the group. He was already a core contributor but now delivered a workable solution and stayed on long enough to see the solution deployed.

The interesting thing to me is that the executive did not draw on the programmer's feeling of pride-in-work with respect to the perfection of the design. Instead, he drew on pride-in-contribution to the community

Combining Rewards

Laubacher and Malone at MIT's Sloan School of Management highlight the combination of rewards needed for high-tech workers (Laubacher 2000). They start with this caution:

"We'll get and keep the best" is not a viable strategy for most companies. Such an approach may be possible for leaders like Sun Microsystems and Cisco, which can offer a compelling package of salary, stock options and challenging work. But not every firm has these resources."

They amend that with the following:

"Because so many of its engineers have become millionaires through company stock options, Cisco Systems likens its workforce to volunteers and manages them accordingly. This is an extreme example, but in many highly skilled fields, talent is seeking something more than the biggest package of stock options. Interesting, rewarding work or a chance to join in a compelling mission now become valuable tools for attracting and keeping talented people."

Open-source projects seem to offer all three of the intrinsic reward mechanisms. The people involved comment on their pleasure in contributing, on the pride they feel about their work, and on their own and others' accomplishments. Those who contribute to open-source software are a notably committed group of people who generate very high-quality code. In their case, software creation clearly is a cooperative "game," done more for fun than for profit.

Even with all of the above discussion in place, it is still not true that a single reward mechanism will work for all people. The space shuttle projects, for example, benefit from people who take pride in finding every mistake and who therefore take their time and review every work artifact carefully. It may be difficult to find appropriate rewards on a project like this if the people involved are looking for high-risk projects that will let them go fast and get rich quickly.

This difference among people is good, because so many different kinds of systems need to be built.

Feedback

People benefit from clear and frequent feedback. In general, the quicker the feedback, the better the effect.

Seymour Cray Fiddles

Seymour Cray, inventor of the world's fastest computers for several decades, gave some talks about his early design techniques.

Fresh out of the university, he was the proud owner of an extra-large radial slide rule. He immediately used it on his first assignment, diligently calculating the parameters for several days.

Walking the halls one day, he met an experienced designer who showed him that it was simpler just to apply a few rules of thumb and build a prototype. He could then test it to see where it was off, make a few adjustments to the design, and bring it to spec.

Seymour Cray illustrated that a little bit of feedback can replace a lot of analytical work.

Of all the published methodologies, Extreme Programming (XP) perhaps puts the most emphasis on feedback, both during design and in the overall project.

XP calls for programmers to work in pairs during design and programming. The second person catches many programming errors during program entry.

The programmers keep unit tests in an automated test suite. Whenever they change a section of code, they run the test suite to discover right away whether they have broken something that had been working.

They produce running, tested code every few weeks. The on-site customers evaluate the new parts of the system and give feedback on its usefulness while the work is still fresh in everyone's minds.

They review their own working habits every few weeks, reflecting on how well they worked in the previous iteration.

Actually, every development team should review its working habits every few weeks, whether or not it uses pair programming or XP. The project "postmortem" that some teams hold at the end of a project happens too late to help the project. Holding regular reflection sessions during the project is much more effective. The team has a chance to incorporate feedback along the way and to work in the time needed to benefit the project.

Periodic mid-project reflection sessions are the single practice common across all of the Crystal methodologies described in Chapter 6. Every two to six weeks, depending on the project's cycle duration, the team gathers to discuss what went well, what didn't, and what to try out during the next period.

With regular feedback reflection periods in place, the team can construct other methods, such as Highsmith's product review sessions (2000), to gain feedback about the project.