Continuing with the last post’s discussion, right now we’re in the business of finding out why are some representations better than others. As a warm-up, then, let’s try to figure out the following:
Which of these representations of geographical data is better?
a) A map of the northeast of the American continent?
b) A city-to-city distance table of the area?
or c) A series of instructions to go from Pittsburgh to Montreal?
Take the I-79 N, then the I-90 E, cross to Canada on the Peace Bridge, then take the QEW until you reach Toronto…
…then leave Toronto through HWY 401 E, take AUT 20, and finally AUT40. Montreal is right around the corner.
(Warning: Not necessarily the best route! According to Ticket to Ride you can also do Pittsburgh -> New York -> Montreal with the same number of train cars!)
So, which is better? The answer, of course, is that this is a silly question. How can we say which representation is better if we don’t know what is it used for?!
All three choices are, for the right tasks, more useful than the others. The first gives you the overall picture of the terrain, an understanding of the geography of the area. The second, information that you could need to plan trips, but that could be hard to calculate by yourself. And the third gives specific details to help you to get to a particular destination.
Defining the purpose of the representation, therefore, is an absolutely necessary first step. Our first rule for evaluating representations, then, is to ask ourselves: what is the representation supposed to be good for?
The nine numbers game, for example, might actually be a better representation than tic-tac-toe if what you want is to practice additions. For some equations, Polar coordinates allow much simpler and more elegant expressions than their Cartesian counterparts. Academic journals, finally, may make for an extremely dry read, but this apparent obfuscation makes for content less prone to misinterpretations than, say, Jorge making his point with plastic trains.
I’m not just stating the obvious. Disregarding the purpose of proposed representations turns out to be a depressingly common mistake, at least in the Software Engineering field:
- Many proposals are offered as a one-size-fits-all. The most prominent example, perhaps, was Doug Ross (back when I was born!) presenting Structured Analysis as a “language for communicating ideas”, as generic as that sounds. Which types of ideas? All types, it seems. Now, SA (which describes processes, and is the grandpa of Data Flow Diagrams) is certainly useful for some tasks, but it’s crazy to suggest that it’s a good alternative to communicate the goals of stakeholders, power relations in an organization, or the stuff I’m writing down here.
- Most language proposals do not consider their context of use. Let’s take UML, for example. Who is supposed to do the modelling? Who is supposed to have access to the models? What other documents are they supposed to substitute? Are the models used before coding -as an explanation tool-, during coding -as a reference-, instead of coding -as abstracted code-, or after coding -as maintenance docs? Or as all of the above? Evaluating UML for each of these possibilities leads to entirely different studies and considerations!
- Some evaluations of representations have incorrect usage assumptions. A comprehension study by Snook and Harrison, for instance, compared a formal specification written in Z to its implementation in Java code. They found that there was no significant difference between them. The problem of the study, of course, is that real software teams do not face the choice of “should we use Z or Java?” The correct question is “should we use Z or something else to specify the system that we will eventually build in Java?”
The list goes on, but I think I’ll stop here since the main idea is clear. Even though asking ourselves what should a representation be good for seems like an evident first step, it is still important to make a point of it to avoid these types of problems.
Next up: Chess studies and radiographies!