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.