Back to 2015-proposals
Title: The map is not the territory
Proposer: Dominic Robinson
Type: Tutorial
Duration: 90 mins
Description:
Caveat: 'Programming abounds with maxims. However you can't capture a complex truth with a glib catchphrase' (andybak https://news.ycombinator.com/item?id=8507632)
The map-territory relation describes the relationship between an object and a representation of that object. In the case of maps, the map is a model of reality which must be interpreted in some context to imply the territory it represents (Wikipedia).
This human process of interpretation is fallible. It can be perilous to trust a map, or more specifically our interpretation of it.
In order to navigate unfamiliar terrain using a map, we must first imagine the terrain it implies and then compare it to reality. When the two appear to match, we assume that we are in the location described by the map. To navigate from one location to another we must imagine the features implied by the map along the desired route and then follow them in reality.
In the same way that we interpret maps we must interpret the source code of a program to imagine its behaviour. In this case the desired behaviour of the program is the territory and we must imagine the territory implied by the map (the source code) in order to identify its flaws.
In some sense the process is the same. A fallible human must interpret the abstract to imagine the real.
The problem is that, in the words of surrealist painter Rene Magritte, 'perception always intercedes between reality and ourselves', we introduce errors. Our perception may cause an imperfect map to appear accurate, or a flawed program to appear correct.
What then are we to do if we accept that we should not trust ourselves?
What can we learn from our struggle to map and explore the physical world?
Today we have digital mapping using satellite imagery correlated with position information from cell tower triangulation, wi-fi maps and GPS, augmented with crowd sourced images and traffic flow data. Has the mapping of software kept up, or do we still revere precious hand drawn maps inscribed 'Here there be Dragons'?
Harry Potter had the Marauder's map (http://www.youtube.com/watch?v=9G_SdCcYFJw):
Harry: Hang on this is Hogwarts…
Harry: So you mean this map shows?
George: Everyone.
Harry: Everyone?
George: Everyone! Where they are, what they're doing every minute, of every day.
Harry: Brilliant.
So, should we be content with 'printf'?
Are there analogies between cartography and navigation that might lead to insights into how we interpret and navigate program code and its behaviour?
In this talk I will look for these analogies and explore the tools and techniques that they might suggest.
I will draw on examples of my own work and that of others, looking at tools both real and imagined.
Implementation details will include:
Flow: Program annotation and instrumentation techniques to capture and visualise control flow in its many forms.
Intention framing: Out of band domain oriented annotations of the intent of executing code.
Exception tracing: Out of band tracing of the propagation and impact of errors to improve error reporting and aid root cause analysis.
Testing with trojans: dynamically loaded code fragments that are triggered using pattern matching against the intent of executing code.
Aims and outcomes:
This talk aims to inspire you to take a fresh look at how you map your software and its behaviour.
To explore new ways to expose its workings and give your intuition traction.
And to give you concrete ideas about how these can be implemented.
2015:the_map_is_not_the_territory
2015/the_map_is_not_the_territory.txt · Last modified: 2016/06/11 14:05 by 127.0.0.1