Following on from my last couple of Innovation Tools blog posts, the next in the series is imaging.
Note: For the purposes of this article I will be focusing on visual imagery. Other sensorial experiences are available.
Due to the depth and breadth of this subject, I’ve found it quite a difficult area to tackle. By way of an introduction though, it’s probably best to start off by defining what is actually meant by imaging. Or at least, what definition I plan on using for the purposes of this article.
Once we’ve agreed on a definition, I’ll seek to refine the scope of discussion and also to understand what problem it is I’m trying to solve by using imaging and visualisation techniques in the first place.
Finally, I’ll talk about some ways that I think imaging might usefully be applied and areas where further study may prove beneficial.
What is imaging?
Noted experimental psychologist and linguist Stephen Pinker talks about how experiences of and interactions with the world are stored in our minds as mental images in his books How the Mind Works and The Stuff of Thought. His works place him in good company, alongside philosophers and earlier experimenters in the field of psychology, all sharing the same basic view that ideas generally can be considered as mental images, with scientific use of the same phrase dating back to William Tyndall’s speech The Scientific Use of the Imagination in 1870.
How the images are actually formed in the minds-eye however is a much more contentious subject, with several pervading theories:
- Dual-Code Theory – Allan Paivio posits that image and verbal codes are used to represent information, depending on whether it’s easier to think about something using a verbal code, e.g. when considering abstract concepts such as love or justice, or as an image code when thinking about something more tangible, an elephant or a house for example.
- Propositional Theory – Dr Zenon Pylyshyn put forward the idea in 1973 that mental images are symbolic. Relationships between objects are represented in descriptive or symbol form and transformed [upon recall] into the verbal or visual code necessary to form the visual image.
- Functional-Equivalency Hypothesis – according to the Oxford Index is “The proposition that imagery, although it does not result from stimulation of sense organs, is essentially the same as perception in the way that it functions.” I.E. a duck waddles and quacks in the minds-eye when conjured up by a word in a book, the same way as it does in real life. Seeing (and hearing) a duck in the mind is functionally equivalent to seeing an actual duck.
I’ve reproduced the theories above because I think it’s useful to have an understanding of them. In particular, I think the functional-equivalency hypothesis is an interesting construct. Many testers will understand that when carrying out their work, they build a [mental] model of the system based upon the questions being asked of the software and the answers they receive – the testing that they are carrying out. The model is always wrong, but sometimes useful and, as the hypothesis suggests, functionally equivalent to operating the actual system – insofar as the information with which the model was built is valid.
What the dual-code theory above also suggests to me is that people generally may struggle to build useful mental images of a piece of software or a complete system due to its abstract nature. The ability of testers, developers and folk working within the realm of IT generally to be able to do so indicates a fairly specialised skill set of which we can be proud. One might even go so far as to describe it as an evolutionary feature.
I don’t personally take much away from propositional theory. Judging by the lack of citations for Pylyshyn’s work in the relevant literature, it doesn’t seem like many other psychology researchers do either.
Based on the small amount of research I’ve carried out, I’m happy with this as a definition:
Mental images are models or representations in a person’s mind of things, concepts or systems that exist outside of that person .
Please do let me know in the comments section if you disagree.
I touched on the main reason we might consider mental imaging or visualisation as a useful tool during our testing efforts earlier. We’re already building a mental image of the system as we work on it. Every time we sit down to analyse, discuss, develop or test a piece of software – we’re leveraging our existing mental model of the system on which we’re working.
Given that we’re already using mental imaging during our testing, one might reasonably ask – is there a problem to be solved here?
In all likelihood, no. But I suggest, since the model is already there, why not think about some ways to increase it’s efficacy and amplify the benefits from it?
We may be able to learn more about and better understand the system or software on which we’re working by carrying out some visualisation exercises. Others have suggested likewise; in his book Thinking and Learning – Refactor Your Wetware, Andy Hunt takes his readers through a TDD visualisation exercise.
I figure there’s two main areas where imaging techniques might be able to help me – again using the testing, consulting, leading modalities as a kind of baseline:
Helping me and others to improve performance by using visualisation techniques
This is a much more established and well understood area. It’s more or less the norm for example in athletics for high performers to use visualisation techniques as an aid to achieving improvements in motor skills in any number of areas. I’ve talked about the book The Inner Game in a previous post as a seminal treatment on the subject (as it relates to tennis and golf). A very brief search for visualisation techniques will bring forth a multitude of articles on the subject, so I’m not going to discuss it in detail here.
Understanding systems and software better by applying imagination scientifically
During my investigations I discovered a couple of research papers that provided some useful insights in this area. Mental Imagery in Program Design and Visual Programming (Petre & Blackwell, 1999) was a particularly useful example, containing the results of a study based on observations of and interviews with programmers, as they were visualising design problems during the course of their work. It’s interesting stuff, with reports of dancing symbols and values as graphs in the head. (I wonder how much of a coincidence it is that The Matrix came out in the same year as this study…?)
Ways in which I think we might usefully visualise a system, along with some quotes from the paper cited above, include:
- Abstract Machines – machines in the mind. “Some of these were vivid, colourful, `physical’ structures – described by one expert as a “great, bristling, multi-coloured scaffolding of pipework and gadgets floating in space” – sometimes described as being in more than four dimensions. Others were logical structures, e.g., “The machines are like data structures – but as operated on … ” Often, data was visible as it flowed through the simulation. All of the experts described moving inside these active simulations, as though they (their perspective) moved around, inside, and through the image.”
- Pictures of implementations – block diagrams or schematics in the mind. “Many of the difficult programming problems – and those most difficult to reason about – involve the concatenation of tools or programs, e.g., outputting probe results into files (or pipes) to another tool, rather than just displaying results on-screen. Hence, experts spend time modelling the behaviour of partially known entities, e.g., this computer must talk to that remote peripheral, which we don’t know much about. It is for this sort of problem that the experts seem to use pictures of implementation structures.”
- Mechanical analogies – “some people, in order to make things thinkable about, generate mechanical analogies – e.g., two-scalar values represented as sliders”. These were felt (by the respondents) to be an inferior form of visualisation, demonstrated by forms such as surfaces, landscapes and presences.
It seems to me that if I want to apply the patterns mentioned above (abstract machines, implementation pictures or mechanical analogies) the way to start might be by combining one or more of the mechanisms with some more conventional visualisation thinking, Some suggestions for getting started are below:
- Get comfortable – this obviously depends on where you are. Getting horizontal in the workplace might be frowned upon, but comfort is a relative term. You might consider going for a walk or something for example.
- Breath deeply – long slow breaths. Counting or trying to imagine air coming in and out of your body can help.
- Start the visualisation – use one or a combination of the visual tools above. Consider the system as a block diagram for example and try to imagine your interaction(s) with it. What are the inputs? What are the outputs? What else is happening in the system at the same time?
I think it’s interesting to consider how visualisation might be implemented by different kinds of tester. For example, a tester focused on functional behaviour, seeing manipulations and their results is likely to have a different visualisation experience to a tester focused on performance, who may instead see imagery related to flow and bottlenecks in the system. Equally a tester who focuses on mobile devices may have a different experience to a tester mainly interested in security.
What are your thoughts? Do you have any experiences of trying to visualise your work? Please do share them in the comments section below.