Книга: Agile Software Development

The Impossibility of Communication

Unknowable and Incommunicable

This introductory chapter sets up two questions: "Can you ever know what you are experiencing, and can you ever communicate it?" The short answer, "No, you can't," creates the basic dilemma that this book addresses.

If you can't know what you are experiencing, how can you reflect on projects, and how can you form recommendations for doing better? Both spending time on irrelevant factors and overlooking important factors will hurt you. This inescapable problem faces every person who is trying to work better: methodologist, researcher, and practitioner alike.

Knowing that perfect communications are impossible relieves you of trying to reach that perfection. Instead, you learn to manage the incompleteness of communication. Rather than try to make the requirements document or the design model comprehensible to everyone, you stop when the document is sufficient to the purpose of the intended audience. "Managing the incompleteness of communications" is core to mastering agile software development.

After setting up the two questions, this chapter introduces the idea of operating at different levels of expertise. A novice listens differently than an expert does and asks for different guidance. This third section discusses the importance of understanding the listening levels of the people who are involved in the project.

The final section relates theabstract concepts to everyday life.

This is the most abstract chapter in the book. If you don't enjoy abstract topics, then skim it for now and return to it after reading some of the later, more concrete chapters.

The Problem with parsing experience

The Wine Label

A good guest, I gave the hostess my bottle of wine as I arrived, and I watched with curiosity as she put it into the refrigerator.

When she pulled it out at dinnertime, she said,

"This will go well with the fish."

"But that's red wine," I finally offered.

"It?s white," she said.

"It's red," I insisted, pointing to the label.

"Of course not. It's red. It says so right here..."

She started to read the label out loud.

"...Oh! It's red! Why did I put it into the refrigerator?"

We laughed and spent time recalling each attempt we had made to check our respective views of the "truth.

"How on earth, she asked, could she have looked at the bottle so many times and not noticed that it was a red wine?"

People who report on software development projects also make mistakes of observation that get passed along as "facts." Requirements writers are not exempt, either. They observe their user community and produce documents that they think contain only ?requirements? but that often contain mistakes of observation as well.

Conflicting Parsing Patterns

When we live through an experience, we parse it, to use the linguistic term. We chop the experience into separate, meaningful chunks that we store for later retrieval. The human mind does this whether we want it to or not.

There are many, and many different, patterns we can use to chop experience into pieces. Each pattern produces a unique perception of the experience. Steak Tasting

When I was first going out to restaurants, I worked at distinguishing and enjoying the taste of steaks. One day, someone told me that it is not the taste but the texture that differentiates steaks.

Parsing Experience

That single idea invalidated what I had thought about steaks up to then and set up a new parsing pattern for the future.

Each parsing pattern leaves small, unresolved gaps in the result. When we parse according to any one pattern and later put our pieces back together, we get a distorted, simplified, incomplete result. We only hope that it is "close enough" to be useful in the ways we use the recollection.

When two people use different parsing patterns, the resulting, differently shaped thoughts give them quite different vocabularies for describing the same events and different results when the pieces are put back together (all distorted, simplified, and incomplete). Thus, one person might describe steaks based on taste, and another might describe them based on texture. Neither description is complete; worse than that, the two people can't share results with each other.

Let's look at this idea in two separate contexts, first with a visual example and then as it applies to software development.

For the visual example, look at how I put together a shape made entirely from 1/8-circle arcs (Figure I-1).

Figure I-1. One arc and an arc pair.

From these and some small circles I put together the next shape, which looks a bit like an owl?s face (Figure I-2). At this point, notice that I have biased your future perception of these shapes. One of the points in this discussion is the bias created by my giving you the name of the shape early on.

Figure I-2. Arcs forming a face.

Putting two owl heads together produces pictures that might look like lima beans, faces, an apple core, or some other shape that you choose to name (Figure I-3).

Figure I-3. Apple cores?

Finally, I build the picture I had in mind (Figure I-4). What do you see in it? How do you parse it into distinguishable sections? Do you see eye shades, embryos, or lima beans? Do you see two yin-yang shapes?

Figure I-4. Complex circle.

Actually, I had in mind two overlapping yin-yang shapes (Figure I-5). Nothing in my intention had to do with arcs, owls, apple cores, or embryos. All of those were secondary effects, artifacts that showed up when I combined the two yin and yang icons, one mirrored and rotated from the other, and parsed the picture according to a different pattern.

The point of my presenting the images in a different order is to illustrate three things:

· Any complex shape can be parsed according to different patterns.

· Our perception about "what is there" proceeds in different directions depending on how we separate elements.

· What we notice is biased by the vocabulary we start with.

Figure I-5. Yin and Yang.

In software development, each person uses his own pattern to parse the experience of being on a project. Each person also falls prey to common errors.

A person might have the notion that humidity is a critical success factor in software development. This person would consequently spend a great deal of effort on measuring and controlling the humidity on projects. A person who is really convinced that humidity is key would not notice for a long time that no great correlation exists between humidity and project outcome. Since I don't have humidity in my project parsing pattern, I couldn't tell you what the humidity was in each of my projects, how it varied over time, or how it might have correlated with project outcome.

A person might believe that following a defined process is crucial to project success. This person would consequently spend a great deal of effort measuring and controlling adherence to the process. A person really convinced that process is key would not notice for a long time the absence of correlation between following a process and the project outcome.

Just as bad as focusing on something irrelevant is omitting something crucial in the parsing pattern. Suppose, for a moment, that a scientist who is doing geo-magnetic experiments in a building is unaware that the walls of the building contain iron.. Not only will she get anomalous results, but she will not understand where they came from or how to alter any of the other variables in the experiments to compensate.

The presence of people on a project is just such a crucial element of project outcome.

Those who do not have the people element in their parsing pattern will simply not notice the effects of the people on their projects. When reading articles that recounts the effect of using a particular new process (for example, Webb, 1999), you may notice that the body of the narrative comments on people but that the conclusion omits commentary regarding people. Researchers who miss this key element in their operating vocabulary cannot use it to adjust the outcome of a project.

The same argument applies to every practitioner, methodologist, and researcher, including me. It is one reason I waited 13 years before writing this book. Much like discovering the difference between texture and taste in evaluating steaks, I kept discovering new parsing patterns for development projects. The results of using the different patterns were so different that I could not commit to any one of them.

These days, when I study a project, I am periodically reawakened to the fact that I don't know what it is that I don't know but should know---what I should be paying attention to but don't have a parsing element for.

This concept of being limited in our awareness of underlying parsing patterns does not reflect something abnormal. The world is not kind enough to give us in advance the yin and yang shapes to use in our daily experiences. We are not first given the parsing pattern and then asked what the result looks like. Rather, we are given a complex experience on which any number of parsing patterns work and in which secondary artifacts easily command our attention. Although this condition can cause difficulty, it is normal and is worth reconsidering from time to time.

Detecting Parsing Patterns

My job as a research and field methodologist is to parse software development experiences that happen at full speed, detect boundaries fit for parsing, and give the pieces names that can be recalled for the next project. Detecting and naming these distinctions provides additional filters through which to examine the software development experience. This work does not create new techniques; it allows us to better detect what is already occurring in the projects and put the pieces back together in ways that will more closely match future experiences.

These days, I ask people to tell a story from a project (preferably something that worked, but any relevant episode will do). Then I see if I can reconstruct the story using the labels that I have in mind about project experience. With slowly increasing frequency, I can. When I can't, I store the story for later comparison. When two stories contain similarities, I look for words I can use to label the common parts.

We are still in the infancy of naming what is really happening on software development projects. The answer is not process, modeling, or mathematics, although those play parts. The answer has much more to do with craft, community, pride, and learning, as we will discuss.

The next step is for methodologists to partner with ethnographers, sociologists, and anthropologists to see if they have words to capture other parts of the experience. Through such a partnership on one project, I learned that system architects act as storytellers. They keep alive the promise and vision of the future system, which is particularly valuable during the confusing early periods of a project. Partnering with social specialists is something I strongly recommend to both researchers and contract software companies who are learning how to work more effectively.

Thinking Inexact Thoughts

We don't notice what is in front of us, and we don't have adequate names for what we do notice. But it gets worse: When we go to communicate, we don't even know exactly what it is we mean to communicate.

In an ideal world, we would have in mind an exact idea of what we want to communicate, and our job would be merely to locate the words necessary to communicate that idea. Usually, however, what we want to express sits in a crack between all the words we possess. We use various words, shifting them around, trying to make them convey what we think we intend to say.

On some occasions, the idea we want to communicate is not even available to our conscious thought. The idea is just a sense that some such idea ought to be there. As we speak, we fish around inside ourselves, hoping that some set of sentences we utter will pull forth the thought we would like to have, to express to our conversation partners.

See how many words it takes you to express a thought, and then pay attention to the fact that what you expressed wasn't what you meant, and that quite possibly, what you had in mind wasn't even what you felt.

This has implications for both designing and communicating.

In the book Sketches of Thought, Vinod Goel (1995) investigates the idea that significant useful mental processing happens in a realm of imprecise thought, proto-thoughts of ideas whose boundaries have not yet been demarcated by the mind.

The study participants commented on the damage done to the developing ideas when the undemarcated thoughts are forced into a precise expression too early. Some processing works best while the proto-thoughts are still undemarcated.

Two of the participants complained about working with precise images: "You almost get committed to something before you know whether you like it or not" and "I have to decide beforehand what I want before I can draw it." (p. 200) One person said:

"One gets the feeling that all the work is being done internally with a different type of symbol system and recorded after the fact, presumably because the external symbol system cannot support such operations." (p. 200)

Pelle Ehn describes software design similarly. Recognizing that neither the users nor the designers could adequately identify, parse and name their experiences, he asked them to design by doing. In the article reproduced in Appendix B he writes: "The language-games played in design-by-doing can be viewed both from the point of view of the users and of the designers. This kind of design becomes a language-game in which the users learn about possibilities and constraints of new computer tools that may become part of their ordinary language-games. The designers become the teachers that teach the users how to participate in this particular language-game of design. However, to set up these kinds of language-games, the designers have to learn from the users. However, paradoxical as it sounds, users and designers do not have to understand each other fully in playing language-games of design-by-doing together. Participation in a language-game of design and the use of design artifacts can make constructive but different sense to users and designers."

That takes us pretty well to the boundary of ignorance: We don't notice what is in front of us, we don't have adequate names for what we do notice, and when we go to communicate we don't know exactly what it is we mean to communicate. The only thing that might be worse is if we couldn't actually communicate our message.

The Impossibility of Communication

That little grimace

you just made across the dinner table

speaks volumes to me,

though it says nothing to the others around us.

You twisted your lips like that yesterday

to show how you felt about that fellow

who had behaved so awfully, when

you were trying to be nice.

I quite agree.

Actually, he rather reminds me of the man

on your left.

I raise my eyebrows a hair

and glance lightly in his direction.

From the stiffening of your top lip as you

continue to chew, it is clear you think so too.

Oh, oh. We've been spotted.

No matter.

Our conversation, although discovered,

will have no meaning to anyone else.

And the poor man on your left will always suffer

from the label we gave him

in this short conversation.

(Alistair Cockburn, 1986)

What is the information content of a raised eyebrow?

Don't look for the answer in Claude Shannon's seminal papers about information theory (Shannon 1963). He analyzed constrained channels, those in which the communication vocabulary is known in advance. In real-world communication, the channel is unconstrained. When or whether you raise your eyebrow is not prearranged. The "stiffening of your top lip" is the invention of a moment, referencing a shared experience with your conversation partner. In the poem above, the partner had that shared experience but the spotter did not. And so the spotter did not derive the same information content as the partner.

Biologists Maturana and Varela have investigated this in the context of biological system. The following wording from The Tree of Life, (Maturana 1998, p.196) describes their results:

"Our discussion has led us to conclude that, biologically, there is no 'transmitted information' in communication. Communication takes place each time there is behavioral coordination in a realm of structural coupling. This conclusion is surprising only if we insist on not questioning the latest metaphor for communication... [in which] communication is something generated at a certain point. It is carried by a conduit (or tube) and is delivered to the receiver at the other end. Hence, there is a something that is communicated, and what is communicated is an integral part of that which travels in the tube. Thus, we usually speak of the "information" contained in a picture, an object, or more evidently, the printed word.... According to our analysis, this metaphor is basically false. ... [e]ach person hears what he hears according to his own structural determination... The phenomenon of communication does not depend on what is transmitted, but on what happens to the person who receives it. And this is a very different matter from 'transmitting information.'"

To put it into words that are simpler, although perhaps less accurate biologically, each living being exists inside a membrane that transfers impinging events into internal signals, which initiate internal activities. It is really only the internal signals that the being "notices," not the external signals. The surprising thing is that the internal signals can also be generated by activities and events inside the being!

A being that "notices" something cannot be sure whether that something originated from an internal or external signal. Thus we "see" images in dreams and hallucinations, when the eyes are closed. Maturana and Varela studied this effect in color vision, finding that we regularly see a color in a scene that does not explicitly contain that color. We generate the color's presence through internal mechanisms.

The "behavioral coordination in a realm of structural coupling" is the correlation between those things impinging on the membrane from the outside and the internal activities that follow. Obviously, we wouldn't last very long as beings if there weren't a fairly good correlation between the outside events and the internal activities generated. It is important to recognize, however, that the internal activities are equally determined by the internal state of the being, its "own structural determination." The information received is not what impinges upon the receiver, but what happens inside the receiver afterwards.

To put this into a concrete example, consider that someone runs into the room and shouts "Fire!" in Japanese. A Japanese-speaking listener receives a lot of information, and immediately leaps up and runs to the exit. The Japanese person next to him, who happens to be asleep, receives no information at all. The external stimulus was never converted into an internal signal A person who speaks no Japanese notices that someone came in and shouted something but received no particular information from the sounds uttered. What each person receives from the shout depends on her internal condition.

Internal Restructuring

Information at the receiver's side is not a static, externally determinable quantity but rather a transient, dynamic personal quantity. The information received is a measure of the internal restructuring that follows the impingement of the signal. It is the quantity representing the size of the change in the receiver's predictive model of the world after receiving it.

Consider these few examples to see this in action:

"I am thinking of a set of numbers. The set includes 1, 3, 7, 11, 13,??

At this point the listener has built up a predictive model that holds those numbers, the fact that they are in the set, and that 5 and 9 are conspicuously missing. They are conspicuously missing, because the typical person constructed a second model, "the odd numbers without 5 and 9," alongside the first.

The speaker continues with: "... 15 is in the set...?

On hearing this, the model grows by one element, that "15 is in the set." No new patterns show up.

The speaker continues with: "... 5 and 9 are in the set...?

At this point, the model changes dramatically, because the sentence contained a lot of "information" for the listener, much more than the earlier arrival of the number 15. Instead of adding two more to the pile of numbers in the set, the listener reduces the model to be "the odd numbers." Hearing that 5 and 9 are in the set added more than two small units information: It converted two medium-sized, competing models into a single, small model. The change in the size of the predictive model was relatively large.

The "information received," being a measure of the momentary change in the receiver, is a transient quantity. Hearing the same sentence twice does not bring the same information the second time. Typically, the receiver's internal predictive model does not change as much, because the restructuring is usually smaller.

Suppose the speaker repeats, "... 5 and 9 are in the set...?

The listener already knows that 5 and 9 are in the set. At this point, the speaker can keep naming odd numbers without disturbing the predictive model of the listener. Each new number adds increasing certainty about the model, but not much more.

If the speaker names an even number, then the listener scrambles to recall which odd numbers got named. He must throw away the "odd numbers" model and remember each number individually again. The moment of adding an even number provides a lot of information for the listener.

Touching into Shared Experience

How do you ever know what message your listener receives? In conversation, she returns messages, and you convince yourself that she really understood your intended message (at least closely enough).

Of course, sometimes you misunderstand her return message and falsely conclude that she understood your message. When you eventually find out, you exclaim, "But I thought my message was clear!"

The success of communication, then, lies in the sender and receiver having a shared experience to refer to. Grimace at the Store

Yesterday, when you and I were at the store, I grimaced when the sales clerk made a particular remark. Today, I make the same grimace. Your mind flashes back to the situation with the sales clerk. Comparing the situation at the current moment with that one, you detect commonality and transfer yesterday's emotional state to today's situation. You get my intended meaning, because we share a memory of the grimace.

When you have an experience sufficiently in common with another person, all you need to do is re-evoke that experience within him. When you touch a second experience in close succession, you link the two, creating new information. The fact of considering those two experiences as relevant to the moment is a new, shared experience for the two of you, one that you can later refer to. In this way, people jointly construct new concepts a little at a time, building new touch points from known experiences. Someone joining at the end of the conversation lacks those intermediate touch points, and must be "brought up to speed", that is, given sufficient touch points to join in.

These touch points grow as a person progresses in experience from beginner to junior, expert, and eventually working partner.

Beginners attend a programming school, where they pick up an initial vocabulary on which to build. They learn standardized notations and simple idioms, which create touchpoints for the low-level elements of design. Those who are learning object-oriented design become familiar with subclassing and polymorphism at the early stages, sequence charts and cardinality soon after, and perhaps a few of the Design Patterns (Gamma 1995). An experienced person trying to communicate a design to someone with this background can only work from these low-level terms. The experienced designer typically experiences this as tedious and missing the overall intention behind the design.

A junior programmer joins a series of projects, building common vocabulary and ideas in stages. The experienced person describing a design to a person at this stage might review some source code, do some joint programming, role-play the operation with some index cards, draw UML diagrams of various kinds, and draw arbitrary scribbles on the whiteboard while talking. The experienced person helps build a different vocabulary in the junior person, and the two of them create new experience they can later refer to.

Two experienced programmers who have not been on projects together refer to common, advanced idioms of design. Their conversation might include fragments such as, "... Just use Composite here, with a Decorator for the side view." "... Set them up as dot-h files, but incorporate..." and so on. Through these large elements of description and additional squiggles on the whiteboard, the one can convey an understanding of the design structure and perhaps reach the intention of the design.

Programmers who have worked together for years have many touch points of shared experience. Their descriptions of requirements and design can be very brief, built on references to previous projects. "...It's the same pseudo-DNA structure we used on the Fox project, but this time separating out the....? The shortcut expressions allow them to communicate and move at a speed not possible with even advanced outsiders. They are able to convey much better the intentions they had while designing.

In professional life, people don't have time to rebuild the vocabulary from the ground up each time they need to communicate. They look for the highest level of common experience they share and build new experiences from there. In no case can they ever be sure the listener really understands what was intended.

Managing Imperfect Communication

Communication is never perfect and complete. Such a thing is not even possible. Even assuming for the moment that you, yourself, know what you intend, the receivers of the communication must jump across a gap at some point and must do that all on their own.

People with similar experience can jump a large gap, working even from mumblings and gestures.

The more different another person is from you, the smaller the communication gap that she can jump . You have to back up, explain basic concepts, and then work forward until she builds her own bridge of experience and understands what you are saying.

There is no end to this backing up. No matter how much you back up, there is always someone who will not understand.

The irony is apparent: In the computer industry, we write specification and design documents as though we could actually ever explain what we mean. We can't. We can never hope to completely specify the requirements or the design.

We have to assume that the reader has a certain level of experience. If we can assume more experience, then we can write less. If we have to assume less experience, then we have to write more. The Russian Programmers

A group in an American firm that was contracting their programming to a Russian company contacted me. They wanted me to teach them how to write use cases for Russian programmers who knew neither English nor the domain very well.

I said, "You can't hope to teach them the domain inside the requirements document. First teach them the domain, then write a short requirements document that speaks to someone knowledgeable in the domain." After trying for hours to get me to reveal the secret of communicating across this enormous gap, they finally admitted they had previously (and successfully) worked simply by putting the key people in the same room. They were just hoping that I had a way to communicate the requirements across the ocean perfectly using use cases.

In the end, they improved on my suggestion. They wrote a short requirements document for their local domain experts and then flew one of those experts to Russia to translate, explain, and generally ensure that the programmers were doing the right thing.

The domain expert could jump the large gap presented by the short use case document and then produce, as needed, and only as needed, communication to fill in and reduce the size of the gaps so that the Russian programmers could jump across.

The domain expert did not attempt to communicate perfectly. He managed the continuous incompleteness of the communications by interacting with the programmers in person and watching what they produced. Luke Hohmann (1998) refers to this as "reducing the equivocality" in the communication.

What the domain expert understood was that he did not have to reduce the equivocality to zero. He only had to reduce it to the point that the Russian programmers could take meaningful action.

Given that complete communication is never possible, the task on a project is not to try for complete communication but to manage the incompleteness of our communications.

The target is to reduce equivocality enough for appropriate action to be taken. That means guessing how much is needed, where to stop, when and how to make the gaps smaller, and how to can help the receivers to jump larger gaps.

Software projects are short on time and money, and making the gap smaller costs both. You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there.

Three Levels of Listening

People who are learning and mastering new skills pass through three quite different stages of behavior: following, detaching, and fluent.

People in the following stage look for one procedure that works. Even if ten procedures could work, they can't learn ten at once. They need one to learn first, one that works. They copy it; they learn it. In this stage, practitioners measure success by (a) whether the procedure works and (b) how well they can carry out the procedure. The 1708 Card Reader

We watched a Humanities major encountering the Univac 1708 card readers for the first time in her first programming class (this was 1974).

Her short program didn't compile. Upset at this failure, she requested help from the student assistant. When the program failed to compile a second time, she became nearly hysterical, and shouted at the assistant in tears: "But you promised me it would work!" Her reaction is typical of stage one learning. The reward for success in this first stage is the sense of, "at least this thing works," and "I can at least manage to accomplish that."

People moving to some new skill domain, whether software or some other, want explicit instructions. In terms of written software development methodologies, this means a thick, detailed manual. The thickness and the detail offer signs of safety for the learning.

In the detaching, or Level 2, stage, people locate the limitations of the single procedure and look for rules about when the procedure breaks down. They are actually in the first stage of a new learning; namely, learning the limits of the procedure. The person in the detaching stage learns to adapt the procedure to varying circumstances. She is now more interested in learning the ten alternative procedures, in learning when each is most applicable and when each breaks down.

A large-scale technique breakdown of this sort occurred in our industry when large software contracting firms, finely tuned to developing software using Information Engineering (IE) architectures, had to begin delivering object-oriented software. After years of unsuccessfully trying to adapt IE methods, they had to develop completely new development methodologies, often regressing through quite unstructured development before discovering new structures to support the new projects. Most of these organizations now have two methodologies, one for IE and another for object-oriented (OO) development.

In the third, fluent stage, it becomes irrelevant to the practitioner whether she is following any particular technique or not. Her knowledge has become integrated throughout a thousand thoughts and actions. Ask her if she is following a particular procedure, and she is likely to shrug her shoulders: It doesn't matter to her whether she is following a procedure, improvising around one, or making up a new one. She understands the desired end effect and simply makes her way to that end.

A team leader who has led a number of projects in different areas doesn't care about "methodology" any more: "Just leave us alone and we'll deliver it," she says. She simply observes and senses that more discipline is needed here, more freedom needed there, more communication needed in some other place. This is the Level 3 practitioner.

The Three Levels and Methodologies

The same three levels apply to listening, coaching, or reading about software development. It is important to respect all three levels, as the following story illustrates: Level Mix-up with CRC Cards Three of us, unaware of these levels of learning, accidentally crossed to the wrong level on our first design mentoring assignment. We decided to lead small design sessions using Class-Responsibility-Collaborator (CRC) cards. (See Beck, 1987.)

The three of us worked slightly differently, which upset the designers, who were newcomers to object-oriented design. They said, "You are all doing something different! Which one of you is right, and why don't the others do that, too!"

We tried saying, "It doesn't matter. They all work." But that did not help the beginners, who were confused: Should they hold the cards up or leave them on the table? Should they write down all the instance variables, or some, or none? And so on.

We knew that the session could be made to work using any of those variants, but the beginners were still in Level 1 and needed one defined way of working that they could apply several times in a row.

A programming book aimed at the Level 1 audience would work to assure the reader that there really is a way of developing software that works, and that if the reader will just follow it, success will follow. Such a book might be called The Science of Programming (Gries 1983) or The Discipline of Programming (Humphreys 1991).

A methodology text aimed at the Level 1 audience describes processes, techniques, and standards in detail. The very detailed templates in the Rational Unified Process (RUP) serve Level 1 practitioners. The big methodologies of Andersen Consulting, Ernst & Young, and the like fall into this category.

A programming book aimed at the Level 2 audience might be called The Art of Programming (Knuth 1997). It would show the reader several techniques for working, with examples and notes about when each is more useful.

A book aimed at combined Level 2 and Level 3 audiences might be called The Laissez-Faire of Programming (think of that as an alternate title for this book) or The Pragmatic Programmer (Hunt 2000). It would name issues to bear in mind and identify techniques that the practitioner might learn, pick up, and put down as needed. The expert will find it a useful library of ideas, but the beginner finds it lacking specific rules.

The Level 3 listener knows that all the published software development techniques are personal and somewhat arbitrary. Discussions among Level 3 people sound distressingly Zen:

"Do whatever works."

"When you are really doing it, you are unaware that you are doing it."

"Use a technique so long as it is doing some good." To someone at the fluent level of behavior, this is all true. To someone still detaching, it is confusing. To someone looking for a procedure to follow, it is useless.

My book, Writing Effective Use Cases (Cockburn 2001), is a technique book with different information for readers at the three levels.

For practitioners at the first level in use case writing, it details the minutiae of use case writing. It provides them with specific procedures to follow. For practitioners at the second level, it contains rules and tips for varying the basic rules. The book does not try to teach anything specific to the Level 3 reader, who will, in any case, find something new in it to try out one day. Instead, it assures the Level 3 reader that the rules are not binding, that a lot of different ways of working can be effective, and that the people at Levels 1 and 2 are being told this, too.

To the extent that book is successful, it permits the Level 1 reader to get specific advice, the Level 2 reader to learn the boundaries of the rules, and the Level 3 reader to move with freedom.

One member in the Crystal family of methodologies is Crystal Clear. Crystal Clear can be described to a Level 3 listener in the following words:

"Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone."

I did, in fact, describe Crystal Clear in those words to a savvy project sponsor. He followed those instructions and reported five months later, "We did what you said, and it worked!"

I interviewed the team leader some months later and his report was about as short as my instructions: "Following your suggestion, the four of us took over this conference room, which has network connections. We kept it for all four months, drawing on the whiteboards over there, delivering software as we went. It worked great."

If you are an experienced software developer and can apply those instructions, then you have no need for an entire book called Crystal Clear. If either you or your sponsor is not at that stage, then you need the book-length version. This version describes key techniques in detail, exposes the principles involved, considers the zone of applicability for this minimalist methodology, and says how to move out of Crystal Clear when the project moves out of the zone of applicability.

One lesson to take away from all this is that if you are reading methodology texts at Level 1, don't become depressed that there are so many techniques and principles to master. Wishing the world were so simple as to only need a single software development technique is a wasted wish. Hire someone who is at Level 2 or 3.

If you read methodology texts at Level 2, note the alternative techniques and look for places to vary them.

If you are reading methodology texts at Level 3, recognize the continued need for methodology definition at Level 1. There will always be people entering the field who will need explicit direction at first, even if you don't.

Kent Beck, author of Extreme Programming Explained, described the use of Extreme Programming (XP) using similar levels. Asked about XP and the five levels of the Software Engineering Institute's

"Capability Maturity Model," he replied with XP's three levels of maturity:

1. Do everything as written.

2. After having done that, experiment with variations in the rules.

3. Eventually, don't care if you are doing XP or not.

The Three Levels and This Book

As described in the Preface, this book is aimed mostly at Level 2 and 3 readers. It has little to offer a Level 1 software practitioner looking for a simple procedure to follow. In fact, a key point of the book is that all methodologies have limitations, areas where they are more or less applicable. It is not possible to name one best and correct way to develop software. Ideally, the book helps you reach that understanding and leads you to constructive ideas about how to deal with this real-world situation. In that sense, the book is aimed at moving some Level 2 readers to Level 3.

Topics for the Level 2 readers include heuristics for selecting a project's base methodology and the ideas behind agile methodologies.

If you are a Level 3 reader, I hope you will find words to help express what you already know.

A few topics in this book are likely to be new even to experienced developers. Most people are Level 1 readers when it comes to the vocabulary for describing methodologies and just-in-time methodology tuning. These are therefore written in more detail.

Shu-Ha-Ri

The three levels of practice are known in other skill areas. In Aikido, they are called shu, ha, and ri (roughly translating as learn, detach, and transcend). To look up information about shu-ha-ri, you might start with a Web search or at www.aikidofaq.com/essays/tin/shuhari.html. The following extract is from that site's The Iaido Newsletter, Volume 7, Number 2, #54, Feb. 1995, "Shu Ha Ri" by Ron Fox, MWKF. (In this extract, the references in square brackets refer to references Ron Fox provides inside his article.) I find it fascinating how his portrayal so accurately predicts our mistaken, early attempt to teach design using CRC cards. "Shu, or Mamoru means to keep, protect, keep or maintain [1]. During the Shu phase, the student builds the technical foundation of the art. Shu also implies a loyalty or persistence in a single ryu or, in the modern interpretation, a single instructor [2]. In Shu, the student should be working to copy the techniques as taught without modification and without yet attempting to make any effort to understand the rationale of the techniques of the school/teacher [3]. In this way, a lasting technical foundation is built on which the deeper understanding of the art can be based. The point of Shu is that a sound technical foundation can be built most efficiently by following only a single route to that goal. Mixing in other schools, prior to an understanding of what you're really up to is an invitation to go down a wrong path. A path where the techniques developed will not have sound theoretical or practical value. In the traditional interpretation of the Shu stage, it is the instructor that decides when the student moves on from Shu to Ha, not the student. It's up to the student to follow the instructor's teaching as an empty vessel to be filled up [1].

Ha, is the second stage of the process. Ha means to detach and means that the student breaks free from the traditions of the ryu to some extent [2]. In the Ha stage, the student must reflect on the meaning and purpose of everything that s/he has learned and thus come to a deeper understanding of the art than pure repetitive

So, What Do I

The mystery is that we can't get perfect communication. The answer to the mystery is that we don't need perfect communication. We just need to get close enough, often enough.

To become more comfortable with the ideas in this chapter, think about what sort of person would be able to understand your system's design from the available design documentation.

Notice the following kinds of communication events:

People around you are blissfully unaware of missing each other's meaning in communication. Notice how often they manage to get by anyway. practice can allow. At this stage, since each technique is thoroughly learned and absorbed into the muscle memory, the student is prepared to reason about the background behind these techniques [3]. In academics, the Ha stage can be likened to the stage where enough basic information is available to the student that research papers of a survey nature could be expected. Ri means to go beyond or transcend. In this stage, the student is no longer a student in the normal sense, but a practitioner. The practitioner must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life. In the Ri stage, the art truly becomes the practitioner's own and to some extent his or her own creation. This stage is similar in academia to the Ph.D. or beyond stage.

[1] Kuroda, Ichitaro, "Shu-Ha-Ri" in Sempo Spring, pp. 9-10, 1994.

[2] McCarthy, Patrick, "The World within Karate & Kinjo Hiroshi" in Journal of Asian Martial Arts, V. 3 No. 2, 1994.

[3] Private conversations with Nakamura, L. Sensei Toronto. Spring, 1994."

With that basis in the three stages of listening and learning, we can continue resolving the mystery of how anything ever gets communicated at all, and what that portends for software development.

Do Tomorrow?

Someone gives you overly vague instructions, so that you can't catch the meaning. Someone gives you overly detailed instructions?so detailed that you can't listen. The people at your next meeting, speaking from different vocabularies, reach to touch into different experiences. People in a different field rely on very different shared experiences to convey information economically. Your waiter writes instructions for the cook in the back when you order a breakfast of "Two eggs over easy with hashbrowns, whole wheat toast, coffee." Ask to look at the order sheet. He probably wrote something like "#3 oe ww " (Menu item #3, over easy, whole wheat).

Notice how inefficient it would be if everyone had to break down their communications into units that could be understood by anyone walking by on the street.

Notice the level at which you are reading different topics in this book.

If you read this chapter at Level 1, work to get comfortable with the notion that the design documents don't contain all the design information. Get comfortable with the notion that experienced designers communicate in shorthand.

If you read this chapter at Level 2, experiment with conveying your system design using UML, design patterns, and references to previous designs. Watch the effects on your colleagues, and notice at what levels they are operating in the discussions.

If you read this at Level 3, see if you can communicate these ideas to someone else.

Оглавление книги