In The Toolbox – Whiteboards

They say a picture is worth a thousand words and in software development there are plenty of words to be said about a great many things from what we’re building to how we’re building it. The old adage “a stitch in time saves nine” is a cornerstone of the agile methodology as we struggle to ensure that the team (customer, developers, testers, etc.) are all on the same page before we start laying down code.

In the modern world of software development where there is a bias towards “working software over comprehensive documentation” the written word is starting to give way to higher bandwidth conversations, most notably just talking to each other face-to-face when the need arises. But words alone are not enough as not everyone can understand a concept just through verbal communication, you can’t just talk slower, and louder, and hope that the other people will just “get it”. The moment a conversation begins to deteriorate is (if you’ve not already done so) probably a great time to double the lines of communication and open a channel to the visual senses.

In an earlier instalment of this column [1] I touched briefly on drawing diagrams, but from the perspective of using my notebook as the canvas. Whilst it has some benefits, for example the permanency, I’ve found that I would much prefer the larger, more transitory nature of the whiteboard if it was on offer. What I’ve come to discover is that I was resorting to using my notebook due to the absence of a better tool (the whiteboard), and because it was a much better tool than the alternative (Visio & SharePoint) for the nature of the message I wanted to convey.

Digital Optimisation

One of downsides of working in The Enterprise is that large organisations are obsessed with exploiting economies of scale and this is very noticeable when you look at the workspace allocated to teams. Open plan offices with banks of desks ensure the maximum density of people and can feel somewhat like a battery farming approach to software delivery. In a continued drive to replace anything physical with its virtual equivalent there is no longer any room for luxuries like whiteboards or Kanban boards. Presumably information persisted as “electronic bits” are so much more versatile than physical media, so why would you want to accept anything less?

The rationale for digitising everything in the office is (I suspect) predicated on a false assumption that doing anything more than once is waste and must therefore be eliminated. The fact that you have not understood what it is that needs doing, and will therefore build the wrong thing, is secondary to the needs of appearing to make progress. By removing the physical tools we use to collaborate we remove the impetus to do so and the whiteboard is one of the largest and most accessible reminders we have available. I can think of no other tool that draws (no pun intended) us in quite like a whiteboard covered in ad-hoc sketches and notes.

Whilst the notion of hot-desking might be great in theory, in practice a team that is going to spend any considerable amount of time together needs a place to call home. This spot needs a certain amount of permanence, ideally closely located to its dependencies, with some surfaces on which the team can draw and attach its information radiators. If you’re unlucky enough to be sitting in one of the rat runs that develop when you have a naïve desk layout then you can use the board as a barrier at one end to dissuade through traffic. If you have noisy neighbours you might be able to use it as a baffle too. Just be mindful that any physical barrier you put up radiates information outwards to ensure you don’t appear sectioned off and hostile towards collaboration with outsiders.

Dumb & Smart Boards

Like most things these days even the humble whiteboard comes in every form from the simplest to the all-singing, all-dancing, Internet Enabled tm version. Your basic large board on wheels is probably the most common breed sighted in the wild as it’s easily moveable, and therefore shareable and large enough to be usable, i.e. hold more than one scribble at a time. Some offices have re-discovered the benefits of such a medium and gone all out and turned every wall into a writeable surface. At one company I worked up you could never find anyone at their desk because they were always at a break-out room or huddled around some random patch of wall chatting and drawing pictures.

For those offices that prefer zero-clutter (which usually means a clean desk policy and nothing on the walls except art or a picture of the CEO) there is the temporary solution – drive-by whiteboards. These are rolls of white plastic film which are statically charged and can therefore be hung on most surfaces, e.g. painted walls and windows. They can stay up for a surprisingly long time and also easily be taken down and re-hung elsewhere. Rather than capture their content in another form they are so cheap that you could just keep the original sketches, at least until you know for sure it’s worth transcribing them formally elsewhere. Apart from a few surprising surfaces where they don’t work the main thing to watch out for is ensuring that you don’t disturb some other team’s peace and tranquillity by pitching up on some free window space near them for an ad-hoc design meeting. Whilst you might enjoy attempting to subvert the organisation by getting stuff done, the complaints from the wrong neighbours may perversely strengthen the argument for virtual collaboration.

One of the earliest electronic whiteboards I got to use was essentially a whiteboard with a scanner and printer welded on the side. You wrote on the board as normal and then when you were done you pushed a button and the white plastic sheet rotated under the scanner/printer combo like a giant roll of fax paper to produce your “hard copy”. Since then the humble board has gotten much smarter, so much so that it’s no longer a physical canvas but a virtual one. Now you draw fake lines, boxes, circles and arrows with (coloured) fake pens and create your sketch in the alternate reality. As if that wasn’t enough your scribble can be added to your SharePoint archive under the guise of a OneNote document where you can relive this masterpiece time and time again.

Only no one does. In the same way that JIRA brings your product development into the electronic age with a promise of taking away all the fuss and nonsense of shuffling around post-it notes, so the electronic whiteboard comes with similar dreams and aspirations. And yet there is still so much friction to working with computer-based tooling that it’s easier to just do it the old fashioned way. Just as the daily stand-up becomes dominated by the time it takes to access the electronic task board on a shared screen, so a quick design meeting becomes bogged down in bizarre networking problems and pens that feel unresponsive.

Don’t get me wrong they are very clever pieces of kit and they can do some pretty neat tricks around transcribing text and recognising shapes. For example where you might previously have had to rub out and redraw parts of a diagram on a physical board to make room you can just select an area and shrink or move it about. If you think your database should have been on the left, or drawn in red ink just change it. And if you think your sketch is destined for a greater part in the world then it has tools to clean it up and allow you to pretend that you drew it in Visio all along.

Of course in the meantime whilst some companies have been developing smarter boards, others have been developing smarter apps to help give your physical doodles some permanence. For some, just using the camera software on your phone will be more than enough, whilst others might want to clean it up slightly (e.g. fix the white balance) before emailing or uploading to their team’s Slack channel or wiki. As you might expect there are a number of free apps for modern phones that are optimised for taking photos of whiteboards which helps reduce the friction a little more, e.g. Office Lens. Just bear in mind that it might be quicker to draw it again when the need arises than shave the yak.

Notation

It’s easy to get hung up on notation, but don’t. Back in the early ‘90s during The Notation Wars the three amigos (Booch, Jackobson & Rumbaugh) called a truce and worked together to product the one notation to rule them all – the Unified Modelling Language (UML). Whilst this caters for a whole slew of different diagram types each with its own sets of symbols, you’ll rarely need this in practice to sketch out a concept; in fact most of the time you can get away with nothing more than some badly drawn squares and a few arrows.

Being a graphic artist is not a prerequisite for being able to communicate with simple sketches, yes you might have to redraw bits if they go really wonky, but that’s the beauty of a whiteboard – rub it off and try again. If you’re drawing some kind of rough architecture diagram and you want to be more adventurous you still only really need three symbols: a rectangle, a tall cylinder (for a database) and a rotated cylinder (for a message queue). You could even throw in a dotted line if you have a need to distinguish more than one relationship. The one thing I do think is important is that every arrow means the same thing – don’t mix-and-match dependencies with data flows as it’s confusing (the arrows usually just point in opposite directions).

A couple of different coloured pens will naturally allow you a little more freedom too, such as when you have namespaces and containers to group things, but as a rule if you find yourself needing lots of different colours (or trying to add hatching to a diagram) you’ve probably gone over the top. The main thing to watch out for though is to keep your pens well segregated! When you’re working with both a whiteboard and post-it notes it’s all too easy for a permanent marker to infiltrate the whiteboard pen drawer and then you’ve got a problem. I think it’s worth sticking with well-known brands, e.g. buy Sharpie’s for your stickies and Staedtler pens for your whiteboard, as you’ll instantly know if it’s in the wrong pile. Also once whiteboards become popular again make sure you have a drawer with a seriously heavy-duty lock to keep them and your board rubber safe from those less well stocked in the stationary department.

As with any technical diagram you should really stick to the same level of abstraction throughout, e.g. don’t try and mix classes into a high-level architecture sketch. Simon Brown [2] has a really nice concept that he calls C4 which stands for Context, Container, Component and Class. I’ve found this is a useful aide memoire when thinking about what it is I want to draw. The static structure of a system is fairly easy to draw using only rudimentary skills and basic shapes, but when it comes to something like a sequence diagramming the swim-lanes approach of UML is as good a notation as any. UML may be much derided for leading many down the rabbit hole of Big Design Up Front, but the U in UML (unified) does at least mean that should you choose to embrace a richer notation it’s one most people should be likely to know.

Words & Pictures

Although I’ve focused heavily on the more pictorial uses for whiteboards we shouldn’t forget that they are more useful than that – you can write words on them too. Okay so they’re not necessarily the best thing for writing lengthy prose, not least due to the unsightly stain you’ll probably acquire on the edge of your palm, but there’s nothing wrong with using the board to help you create lists of stuff. Or you could use the top corner to write up a point of focus (aka sprint goal) for the next few days to continuously remind the team about what over-arching business event or theme they should be collectively working towards.

Even though you might be decomposing your work into epics, stories and tasks, there is still a need to flesh out details at the point of implementation. For instance you may have defined some loose conditions of satisfaction [3] at an earlier planning stage, but now that you’re ready to work on the story in earnest it would be useful to lay down a more formal set of acceptance criteria, perhaps with the other 3 amigos (BA, developer and tester). Naturally the board is a good place to work out a list of happy and sad paths that need to be catered for. Or maybe you need to sketch out something around the UI, perhaps the developer and tester need to factor some kind of test API into the design, or someone from ops needs to see how this new feature affects the monitoring of the system. A story is just a placeholder for this conversation.

Whilst index cards are nice for arranging on a desk, they don’t stick very well to walls, unlike Post-it notes. I’ve known places though where you aren’t allowed to stick Post-it notes on windows and their walls are painted with some kind of anti-sticky-note paint, so the board may have to double up as both a task board and design tool. Personally I’ve always been fonder of arranging things on a vertical surface than horizontal, but I’m sure mileage varies greatly here.

The one thing I never use the board for is writing code. Apart from an interview where I’m being specifically asked to write code on a board, I’d always do it at a terminal using a tool custom built for the job – the text editor.

Write On / Wipe Off

The humble whiteboard is becoming an endangered species in the corporate world. It’s a sad moment seeing one sat in the corner of an office with an architecture diagram from years ago almost burnt into it because the pen ink has had so long to dry out. Almost every day for a board should be different as people come and go, stopping only briefly to chat, sketch, write, arrange, sip coffee and reflect before moving on. These bursts of activity will be interspersed with periods of serenity, before once again the slate is swiped clean and the hullabaloo of collaboration punctuates the air once again. Whiteboards are for living.

References

[1] C Vu 25-4, http://www.chrisoldwood.com/articles/in-the-toolbox-pen-and-paper.html
[2] http://www.codingthearchitecture.com/2014/08/24/c4_model_poster.html
[3] http://stackoverflow.com/questions/3697466/can-you-clarify-the-differences-between-conditions-of-satisfaction-cos-and-acc

Chris Oldwood
14 June 2016

Biography

Chris is a freelance programmer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros. These days it's enterprise grade technology in plush corporate offices. He also commentates on the Godmanchester duck race and can be easily distracted via gort@cix.co.uk or @chrisoldwood.