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.