Drawing Skills for Computing

Drawing pictures is a vital skill for computing. Pictures of our designs in particular.



In an agile world the idea of using (or teaching) UML is questioned. One person I know is particularly questioning, but he's had to do some of the teaching! The rationale is about the code documenting itself and the small cycles not needing a large and separate design phase. I got taught a couple of analysis diagram types in education (flowcharts, ER diagrams, state transitions, Grady Booch's OO, Yourdons's OO, Petri nets, probably some more) and picked up others (including UML) along the way so they've kind-of always been part of my skill-set, which may bias me. These days I'm more or less agile, but I still see a place for pictures. Today was a good example: we're working with quite a complex state machine that needs to evolve: to fix bugs, to be more efficient, to reflect an evolving ecosystem of devices. It was time for a review of what we have, to think through any design faults before the next deployment and to identify and prioritise the next development steps. The wide whiteboard was the obvious tool - there are about 15 states and 25 transitions. Keeping the whole on-screen (and legible) or in-head is hard. New colour pens to annotate external systems and possible changes and consider their impact on the whole was very helpful. A panoramic picture app for recording it at the end was a reasonable thing to try.

I also use pictures on a notepad, to think through problems, its easier than tractor-feed printouts on the floor. I publish snapshots of my work, where pictures convey an overview idea so much faster than code.

A common vocabulary just makes sense for all this. So I remain an advocate of keeping a set of visual notations in what computing people (not just programmers) learn - it forms a common language and reduces complex problems to something more manageable. If we can't communicate complex ideas easily and reasonably precisely, either within a team or beyond it, then I think we'll hit a wall of what we can do. Not because there aren't smart people in each role, or because we're trying to build something in too large a step - but because at some point you have to interact, and at some points all the little agile steps build up to something that needs perspective.

So, drawing skills? Doesn't have to be A-grade technical drawing. It does help to be able to mix drawing what you see and something imagined. A willingness to rub bits out and improvise are important. Talk about what you've drawn too. But take a break from the screen and the text now and then.