The Map is the Minefield

The map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for it’s usefulness.

– Alfred Korzybski, Science and Sanity

 

Today abstraction is no longer that of the map, the double, the mirror, or the concept. Simulation is no longer that of a territory, a referential being or substance. It is the generation by models of a real without origin or reality: A hyperreal. The territory no longer precedes the map, nor does it survive it. It is nevertheless the map that precedes the territory—precession of simulacra—that engenders the territory.

– Jean Baudrillard, Simulacra and Simulation

 

And those who were seen dancing were thought to be insane by those who could not hear the music.

– Friedrich Nietzsche

 

More than anything else, what you are as a business analyst (or a human being in general) is a maker of maps, but maps of what? Surely not the map that will get you from Baltimore to Kalamazoo, or Bangladesh to Bonn. We are also not talking about a map of the star field above our heads, or the treasure maps we may have made as children. By map I mean a shared understanding of the way things work. Nature may not proceed or measure things the same way we do, but mathematics is a useful way of mapping events that occur in nature, just as our descriptions of things in language allow us to agree and communicate about what those events are. For us, a particular map may be a requirement, or a set of requirements. Or it may be the distance between what already exists and what it is being proposed.

Let’s say you have a new requirement. You have to define how to make a software application that does A and B also do C. First you have to identify what A, B and C are. What you know about A and B right off the bat is that the software does something when you prompt it to do something. You might not even know the intention behind what it does. You might enter a group of numbers, and those numbers get used in some formula and another number appears. B might present the numbers you entered, and the resulting number in a  graphical representation. You see what it does, but you have no idea why it’s doing what it’s doing. On the other hand, with C you may understand the why, the intention, but not yet have a model for how to go about satisfying that intention.

Every piece of code ever written has an intention and it may be safe to presume that every piece of code that will ever be written will have an intention, except for occasions of art or pure experimentation where someone may actually decide to create code without intention, but let us presume that at its very essence a piece of code is intention-based, that all coding is based on intention.

Functions A and B may be, respectively, an algorithm that estimates the number of eggs someone’s chickens lay that actually get sold, based on statistical expectation, and a visual representation of sold eggs versus investment of chicken feed. The new function, C, may be a cost analysis of feed to yield that takes into consideration typical seasonal increases and decreases in both the price of feed and egg purchases. It is a somewhat imagined translation of what it costs to produce an average egg, though an average egg doesn’t in truth exist, since some chickens will eat more and lay less, and others will eat less and lay more. There are also always unexpected, unaccounted for, influences. Perhaps the chickens toward the middle of the chicken coup are better shielded from the weather in the winter, and more prone to the heat during the summer, so there will be variations in how individual chickens produce based on feed consumption over time.

The key is the cost analysis is a very high level generalization of an imagined relationship among things in the world that are made into variables. I emphasize the word imagined here because it will come up over and over again in our work. Yes, there is a real relationship between how much someone is going to feed her chickens and how well they produce. If she doesn’t feed her chickens they will die. If she overfeeds them, there may be some other unwanted result. But there is no way outside a laboratory, where all other variables (at least those one can account for) can be controlled, to define quantitatively how many grains of feed produce a single, saleable, egg. There are too many factors. All your work in developing the algorithm is based on very limited data and a simplified view of the interrelations of things, the very flows of life that allow for egg-development as well as the forces in the market that may enable and inhibit their distribution. Such and algorithm may however be useful to the chicken farmer who needs to estimate how much money she needs to set aside for feed, and how much she will have leftover to rebuild part of her coup that was damaged during a storm last winter, or to expand her business further.

In another scenario, you may not even asked what the proportion of feed costs to egg yield are, but given the net of all expenses for the entire farm, including payroll, construction costs, machinery and maintenance, and so forth. An investor in the farm may not even want to know that level of detail, but perhaps only wants to know the cost to revenue relationship per year for this farm compared to other egg farms. He may include his investments in this chicken farm as part of an investment portfolio that he sells to other investors, who know nothing about the farm, but only the numerical results of the investments. He may want you to chop up the entire portfolio into investment units, or shares, that represent a part of the ownership or debt to the purchaser of the units.

As you get further away from the actual physical things happening in the world, you go higher and higher up in the levels of abstraction, and into a world of pure invention. That’s where most of us live. And it’s all maps of various kinds, some of seemingly actual things, and some of generalizations made of other maps and ideas that may assume that there are patterns to look out for, conspiracy theories of sorts about the way events may haphazardly coalesce and influence each other.

A user of these maps may even decide to design farms, or the very genetic make-up of the eggs themselves, to conform with an investment strategy. There may be a presumed need for additional resources, like water, that may belong to the community, but is required by the algorithm to optimize the strategy. It’s hard sometimes to decide whether we are talking about a benevolent innovation, or merely the deceptive fascination of the simulacra – ideas run wild and generating a misleading and destructive parallel world, which may have been innocent enough at the outset.

And so our map-making can have social and moral implications as well. Maybe not this piece of code you are working on, but perhaps the accumulated codes you have and will have worked on, the very way you work and address the problem-to-solution process, your style of working, since it is the habits that emerge from today’s efforts that shape the assumptions you and others will conform to tomorrow. We need to be awake to these effects. At least awake, if not actively shaping something useful and beneficial. As the artist Joseph Beuys repeatedly said, we are all artists, and by that he didn’t mean that we all were the makers of decorative and petty things. We all create, every day, just to keep ourselves alive and happy. Our every step produces another line on the map we’re not even aware we are creating, another set of shifts of habit, assumptions.

So as a generator of requirements documentation, you may not have the opportunity at every turn – since on a day-to-day basis it can come down pretty mundane stuff – to create something awesome and beautiful, but over time you have a choice to move, at least through the development of style, those habits of practice in a direction that helps to shape a culture we can love and be happy to leave for others.