In 1931 Alfred Korzybski gave a presentation at a meeting of the American Association for the Advancement of Science in New Orleans where he used the phrase “the map is not the territory.” Korzybski used this phrase to mean that people in general do not have access to absolute knowledge of reality, but merely possess a subset of that knowledge that is then tinted through the lenses of their own experience. He further added that it is important for people to know that their understanding of things, “the map”, is not a true representation of reality itself or everything represented by reality, or “the territory”.
A Belgian surrealist artist Rene Magritte used Korzybski’s notion in his work, and described the idea that was the foundation of his art as an understanding that “perception always intercedes between reality and ourselves.” One of Magritte’s most famous works was an image of a pipe with a caption below it that read Ceci n’est pas une pipe (“This is not a pipe.”) This piece was meant to illustrate that the painting of a pipe was not a pipe itself, but a representation of what his audience would associate with a real pipe.
So what does the phrase “the map is not the territory” mean for software development?
Software development teams have a very difficult job. They must elicit requirements for a product that doesn’t exist. In that effort, the customer then tries to describe this non-existent product, while the software development team imagines what the customer is describing. In a waterfall approach, the first time that anyone finds out if what the development team built is what the customer wanted, needed, or asked for is during user acceptance testing. This is very understandably why most waterfall projects do not end perfectly, or in most cases are far from perfect in their delivery.
Why does this so often happen? Korzybski would describe this as being a suitable example of his concept that the map is not the territory. Software developers spend a great deal of time in the requirements gathering phase attempting to construct a perfect map of the product territory. But this map, this understanding of what the customer wants, generally results in the delivery of a product that misses the customer’s needs for the product. It is not that the developers were not ernest enough in their requirements gathering efforts, it is not necessarily that the customer did not do their best to document their requirements, it is simply the nature of misses that occur when we try to translate what they customer is saying to what we are thinking, and then to what we ultimately end up building. It would be like trying to construct a perfect map of the American coast based on the description provided by an explorer familiar with the area. It just would not be a representation of any accuracy or quality.
So how do we proceed with software development knowing that this problem will continue to be a part of most software development projects? Agile fundamentals recognize that in software development, the map is definitely not the territory. So in light of this we only build small bits before going back to the customer to verify if our territory matches their mental map. Showing working software is truly the only real way to ensure that what we are building is what they asked for, and more importantly, what they need and want.
The first step to avoiding the pitfalls of mismatches in understanding the requirements for a product is to open our eyes and check with our customer each step of the way. We need to be aware that even with simple requirements, a simple product, or an impatient customer, there exists the likelihood that what we hear as developers is not going to perfectly match what the customer thinks they are saying.
I use an exercise to demonstrate this phenomenon and recently had the opportunity to use it with a group of over 100 business analysts. Each person participating in the exercise is given a single sheet of white paper, they are asked to hold it up in front of them, and then they are asked to close their eyes for the duration of the exercise. Following everyone closing their eyes, I provide a series of very simple instructions (fold it in half, rip off a corner, etc.) while I am also following my own instructions. They are playing the part of the software development team, while I play the part of the customer. After a series of 4-5 instructions, or requirements, everyone opens their eyes, unfolds their paper, and then compares what they “built” to my requirements. Out of 100 people participating in this exercise, would you like to guess how many folded their paper so that it matched my requirements? If you would like to find out, I have the video of this exercise posted here (it is within the first few minutes of the presentation.) Even with simple instructions, it can still be difficult to match the map to the territory.
A successful Agile team recognizes that their map will rarely match the customer’s territory without regularly opening their eyes and checking that their folds match the customer’s folds.