The Map is Not The Territory

I first came across General Semantics in the works of A.E. Van Vogt. His stories from sci-fi’s ‘golden age’ had a common theme about the infinite potential of ‘the human nervous system’ which was very appealing to a brainy weedy kid. Part of the development of human kind, in these stories, involved a rejection of Aristotelian thinking. This Non-Aristotelian thinking is based upon Korzybski’s General Semantics. But wait a minute what has this to do with code and RSpec and Cucumber?

One of General Semantics keys is “the map is not the territory”, and that is what this article is all about. Looking at features and specs as maps helps me understand how to use these tools more effectively and also addresses some common frustrations that people new to BDD and these tools experience. But first a little aside into frustration and why its such a good thing.

Frustration is good - read the signs!

Frustration is good! What are you talking about!!

Frustration is your brains way of telling you that something is fundamentally wrong. Your brain is saying STOP! Think Again! So what do we do? … Well most of the time we ignore our brain, or we blame something/someone, or we ‘work our way through it’.

See frustration as a warning light on the dashboard of a car. Don’t ignore it or you’ll “run out of fuel”, “blow up your engine” etc. Frustration is a great early warning system, telling you that you don’t really now enough about what you are doing. So stop and use the most formidable thinking machine on the entire planet - your brain!

Features as Maps

If a feature is a map what is the territory? Well I think features are a two way map between territories. These territories are

1. The intentions of the application sponsor (the person or persons deciding that the application should be built and what its contents will be)
2. The application

The Qualities of Maps

All maps have a scale, which performs two functions

1. Show the distance represented by any two points on the map
2. Determine the level of detail shown on the map

Features have a large scale, they cover a wide area with little detail. They have to be this way. The first territory they map is a vague amorphous entity which cannot be seen, touched or expressed particularly easily. This is difficult terrain to map so features use (as much as they can) one of our most powerful tools - natural language. The second terrain they map is a small precise highly defined territory. In fact it is so precise that it can be accurately described and even executed using just two characters 0 and 1. Features don’t really make much of an attempt to map this terrain. They are more interested in executing (in the computational sense) the terrain. However they can be quite useful as a map of other maps of the application, its UI and source code.

Feature Frustrations

This article was inspired by frustration expressed in a post on the Cukes mailing list. This frustration (IMO) is based on not understanding the scale of features map. Detail is not appropriate in features because detail is not in the territory of the application sponsor. If developers pollute the feature map with their level of detail then the application sponsor can no longer read the map. The map becomes too large and to dense.

Fortunately features have other important functions apart from being a map, so it is reasonable (essential?) to compromise on what they show. But once we understand how detrimental detail is to features then it becomes obvious that they must be supplemented with other tools.

Writing this has made obvious something that I was barely aware of that is that software has to be specced and tested by a suite of tools. An application is too complex a territory to have just one map. Once it becomes obvious that an application cannot be mapped by one map it is a small leap to realise that an application cannot be tested with one test tool, specced with one language. Just as we have to map at different levels we have to execute and test at different levels. I used to be frustrated by having to combine features with specs, and then think about controller specs, helper specs, view specs, user acceptance testing … Now instead of being frustrated I realise that the need to learn a suite of tools and the necessity of creating a range of maps is just a natural result of the character of the territory I am working in.