INTRODUCTION

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.