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.