Whiteboard diagramming

As you probably know if you’re keeping in touch with the software engineering research community, there has been plenty of research on conceptual modeling in recent years. Most of it focuses on the creation, refinement, and formalization of modeling languages (UML, for instance). But the question of how do software developers truly use diagrams and modeling languages, if at all, is often left unanswered –researchers tend to assume that “if you build it they will come”, and hence (as I’ve complained before) their proposals grow more and more disconnected from the real needs and habits of developers.

This is why fieldwork studies that give us insights into the software development process are so valuable: they help to reconnect the software academia and industry.

A particularly interesting empirical paper on diagramming was presented by Cherubini et al. [1] at the CHI conference this year. It reports how and why software developers at Microsoft use diagrams, and what graphical conventions do they use. From the abstract: “Results show that most of the diagrams had a transient nature because of the high cost of changing whiteboard sketches to electronic renderings. Diagrams that documented design decisions were often externalized in these temporary drawings and then subsequently lost.”

There are several juicy bits in this paper. Here are just some of them:

  • A distinction between the use of models for understanding, for designing, and for communicating, andthe differences in formality and effort put into each of them.
  • A breakdown of drawing media used when modeling (interestingly, diagrams are almost always drawn in whiteboards).
  • Some thoughts into the lack of use of graphical standards (“It is clear that UML does not, in general, reach a sufficient cost-benefit ratio in the minds of developers to warrant its use.”) and the lack of synchronization between models and code (“Visualizations in documentation were often out-of-date and they were rarely used for the core of the development process.”)
  • Reports on very subtle design ideas that are elegantly conveyed through diagrams, but that are a real challenge to formalize: “We decided to give it this butterfly shape to emphasize that the contract in the center shouldn’t change and should be small…”.
  • A discussion on levels of abstraction allowed by current graphical notations: “…developers need to understand both the microscopic details of the code and the macroscopic conceptual structure. (…) No current [standardized] view conveys both levels of abstraction simultaneously.”

It’s worth a read, but unfortunately you need an ACM subscription to access it. I’m sure you can get a copy if you email the authors, though.

[1] Mauro Cherubini, Gina Venolia, Rob DeLine, and Andrew J. Ko, 2007. “Let’s Go to the Whiteboard: How and Why Software Developers Draw Code“. Proceedings of the SIGCHI conference on Human factors in computing systems (CHI 2007).

About Jorge Aranda

I'm currently a Postdoctoral Fellow at the SEGAL and CHISEL labs in the Department of Computer Science of the University of Victoria.
This entry was posted in Academia, Conceptual Models, Information visualization, Software development, UML. Bookmark the permalink.

4 Responses to Whiteboard diagramming

  1. Pingback: The Third Bit » Blog Archive » How and Why We Draw Code

  2. Neil says:

    Naturally the issue of corporate culture must be raised. The paper was excellent and very revealing, but external validity is hampered by the focus on Microsoft. To what extent are these practices common across all software organizations? As a rough bet I would say the results might generalize quite well.

    Another question might be, does such use of diagramming (given the benefits the paper ascribes to diagrams in the intro) improve Microsoft’s products? I imagine in the early days at MS, ‘write code’ was the mantra, but has what worked for Bill G in 1982 scaled well to 2007? I’m not sure. Vista, for one, seems to have some issues.

  3. Jorge says:

    Neil,

    Yes, external validity is questionable, and it has to be when dealing with case studies such as this. Furthermore, Microsoft is such an outlier in so many ways that one simply can’t conclude that what happens there happens everywhere. Still, whiteboard diagramming seems to be the rule, rather than the exception, in every company I’ve ever visited but two (and in these two, diagrams had to be included in the spec for contractual reasons).

  4. georgetui says:

    Hello,
    Great forum!
    I found a lot of interesting information here.
    Does this forum helpful for you also?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s