Imagination

Imagination might not be the first quality you think of when you think of people who build computer systems.  However, I think it’s really helpful for many parts of the process – designing, building and testing it.

Old English Digression

First, a digression into Scandinavia via UK primary schools.  This is my friend Tim Eagling (left) and his colleague Jon:

Together they are Time Capsule Education.  One of the things they do is go into schools to help children with their creative writing.  So that the children can have imaginations they can apply to their writing, Tim and Jon first feed their imaginations via real experiences.  They don’t just narrate Beowulf, they immerse the children in it – so they can see the armour and feel its weight, remember the swish of the axe through the air and so on.  (They do the same about spy stories, dragons and so on – if you are involved in a school in the UK, I recommend you look them up.  Tim was a teacher and teacher of teachers, so he knows what he’s talking about.)

I think that creative writing is like building a computer system.  There is a necessary formal component (the rules of English grammar etc, or some API’s specification and the rules of Java / C# and so on), but there also needs to be imagination in order to create something.

You might be sceptical, so I’ll go through a few different roles where I think imagination is useful.

Architecture

One of the things that has helped me when thinking about the big picture version of a computer system is to consider the main lumps of information that it will use – user, product, price etc.  At this stage I’m not thinking about the details such as the physical data model, just the 5 or so key things that are essential to the problem I’m trying to solve.

I then work through each one and imagine its lifecycle – its creation, use and disposal.  For each stage I try to answer basic questions like who / what / when / how / where.  These things don’t exist yet; they live only in my imagination.  I then need to communicate what my imagination sees to other people like colleagues and the customer, and that communication is the subject of other blog posts.

Similarly, I consider all the external systems that my system will need to deal with.  I then imagine all the ways a given external system will interact with my system – when things go well and when they don’t.

Users

There are two levels to this.  At the higher level is a similar exercise to the one above, where I imagine all the different kinds of user.

The lower level is the realm of user experience (UX).  Unlike with data, you can actually talk to users to work out how they want to interact with the system.  If talking to users isn’t possible for whatever reason, imagination is a good plan B.

I’m talking about things like customer journey maps.  If you can’t talk to users, you need to put yourself in their shoes i.e. imagine you’re them, and then consider how you would interact with the system.  What do they want to achieve, how does one interaction fit in with an overall flow (which might include physical things like shops or call centre staff or packaging)?

Trying to picture The Matrix

When I’m working on some software, I can’t just blindly type in characters.  I need to have some idea of what I’ve already made and where I’m trying to get to.  This mental context is what disappears when I get interrupted and is an invaluable guide as I work (which is why interruptions are costly to programmers).

Sometimes part of this context is something I’ve scribbled down or even put in a document, but mostly it’s just in my head.  I don’t keep a carbon copy of the source code in my head; instead it’s more like a fuzzy kind of UML, to capture the important bits of structure and behaviour.  This could be at more than one level of abstraction at once – I think about the level I’m working on and at least the level above it and below it.

As I said, I don’t usually put in the effort to get this out of my head and onto paper or into a file.  It lives only in my imagination, and without it I’m just stumbling randomly about.

Reviewing and testing

These are similar but different.  Reviewing what’s in front of you is one thing, but knowing that something is missing is harder.  Some of this can be helped by diligence – checking against requirements, your knowledge of the rest of the system and so on – but it’s helped by imagination.

In both reviewing and testing it’s useful to ask yourself: How can I break this?  This is particularly true in penetration testing, although that often needs deviousness and hard work too.

Another useful question is: How will this be used?  And related to this: How could this be used in ways the author didn’t think about?  More avenues down which your imagination can usefully run.

This is why automated tests (or checks, to give them their proper term) are good but no substitute for a skilled human tester.  Michael Bolton says this kind of thing much better than I can.

Bits vs bolts

A fairly enlightening comparison is in this video of Colin Furze and Tom Scott working on a common project.  On the one hand there’s Tom Scott – sitting at a laptop, thinking and typing.  He looks a lot like most people do when doing computer things.  On the other hand there’s Colin Furze – sawing metal, welding metal, screwing large wooden boards together with an electric screwdriver.  Note that this is a tame version of Colin Furze – he’s often a bit more extreme.  There’s little need to imagine the metal while you’re working on it, or imagine what the saw’s doing, because you can hear it, see it and feel it.

Summary

You need formal stuff and structure to develop computer systems.  Imagination is very helpful too.  Given that, it’s worth considering how you feed your imagination.  Despite their many skills, I don’t think that Time Capsule Education could help you there, so that bit’s up to you.