Napkins: A tool for the trade

Ralf Westphal — Sat, 14 Jun 2008 09:52:06 GMT

You know how that is when you start to immerse yourself into some new subject and all around you related stuff suddenly seems to sprout and blossom. Stuff you had never seen before and you doubt, existed before.

This is happening to me right now. Until a couple of days ago, I was not much concerned with napkins. Pretty much they were below my concious radar. I used them when appropriate, but otherwise gave them not much thought. Except maybe for not liking napkins out of real fabric much. They are stiff and lack absorptive capacity.

Anyway, now that I´ve read Dan Roams book and started this blog, napkins seem to be all over. Not only have star architects been asked to confine themselves to sketches just on napkins. Napkins since have transcended their typical use at tables and become veritable creativity tools:

source: http://www.tranism.com/weblog/2007/11/napkin_notebook.html

Cool, isn´t it. I´d love to order a couple of these notebooks, which surely are excellent software architecture tools. Who would still want to use Rational Rose or Visual Studio Team System Architect Edition, if one has such a powerful and flexible tool at one´s disposal?

Unfortunately, as it seems, I´d need to travel to New York to buy such notebooks. They are on sale only at the MoMa.

Until then, though, I can use the only version of this tool:

source: http://www.napkinnotebook.com/

And it´s for free!

IBM and Microsoft: when will you bring software architectural drawing at our finger tips like this?

Don´t try to impress with your drawings!

Ralf Westphal — Tue, 10 Jun 2008 23:06:17 GMT

Why did I choose the napkin to promote as a canvas for software architectural drawings? To be honest, except for my general belief in the virtues of simplicity it´s also somewhat a hommage to a book I recently read: The Back of the Napkin: Solving Problems and Selling Ideas with Pictures.

Dan Roam impressed me with his creativity and his ability to depict the essence of all sorts of stuff in clear and simple pictures - all fitting on the back of a napkin. Before I´ve read his book I either did not give size of architectural images much thought or I complained about the limited size of displays compared to the huge blueprint tables for building architects.

I always envied them for their large sheets of paper filled with all those symbols describing a whole world to be built and lived in. The overview such blueprints provide seemed important to me. In comparison to that, looking at an UML diagram on a 1280x800 screen felt awkward.

That has changed, though, thanks to Dan Roam! I no longer feel hindered in my creativity and expression by a small display. Right to the contrary! I think limited display size or a consciously chosen small canvas help architecting software. Why? Because a small canvas naturally limits the number of "things" you can depict at the same time. A small canvas thus constrains the complexity of the design you can draw. And that´s a good thing!

Traditional building architecture might not need such constraints, since it´s dealing with static objects. But software is a different beast. It´s not static at all, it´s highly volatile, constantly evolving, never finished. That´s why I recommend, to keep depictions of it small.

You probably think drawings like this

source: http://openalchemy.org/index.php/OpenAlchemy_Wizard_Tour

or this

source: http://www.roxsoftware.com/ug/

are the norm and why should it be different. But from the point of view of someone trying to understand (!) what they show they are, well, hard to grasp. Whoever draws a diagram does not have much of a problem with its size. He understands the content perfectly well - otherwise he wouldn´t be drawing it. But once you switch sides and need to understand such depictions, the situation changes. Hours upon hours of valuable time are invested into understanding such drawings - whereas much effort could have been saved, if the drawings were kept smaller and simpler.

If you´re an expert in fuel injection pumps the drawing on the right might be easy to read. But there are always less experts than novices, people who first need to learn about a technical system. They are easily (and unnecessarily) overwhelmed by such images.

That´s why I´m saying: Don´t try to impress anybody by putting everything you know about a software system into just one big picture. Try to walk in the shoes of the many (occaissonal) viewers of it who don´t have much time make sense of a ton of boxes and arrows.

Of course the capacity of the human visual system is mind boggling. We can spot a familiar face in a crowd and scan thousands of images in a folder or on a light table. But that´s "simple" pattern recognition.

Understanding (!) a software architecture on any level of abstraction is different. There might be patterns to recognize, but before that the meaning of the structural elements and their relationships needs to be clarified. And that´s what costs so much time. And that´s what benefits from consciously limiting the size of software architectural drawings.

At times larger drawings for overview might be ok. But mostly you should think "small is beautiful" ;-) Focus yourself on whatever fits on the back of a napkin. You can use more than one. Help yourself...

Why a napkin?

Napkins: A tool for the trade

Don´t try to impress with your drawings!