let's go to the whiteboard: how and why software developers use drawings
DESCRIPTION
Software developers are rooted in the written form of their code, yet they often draw diagrams representing their code. Unfortunately, we still know little about how and why they create these diagrams, and so there is little research to inform the design of visual tools to support developers' work. This paper presents findings from semi-structured interviews that have been validated with a structured survey. 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. Current visualization tools and the software development practices that we observed do not solve these issues, but these results suggest several directions for future research.TRANSCRIPT
Let's Go to the Whiteboard: How and WhySoftware Developers Use Drawings
“The cobbler's children
are the last to get shoes”
M. Cherubini -EPFL
G. Venolia -MSR
R. DeLine -MSR
A. J. Ko -CMU
Pict
ure
cred
it: D
. Rig
aud
Which of these two diagrams is more useful
to software developers?
credit: w3.org
AB
Previous research• Sketches and formal drawings play
major role in other engineering&designdisciplines– K. Henderson [1995]– B. Tversky, et al. [2003]– B. Tversky [2001]
• Software developers keeps criticalinformation in their heads– T. D. LaToza, G. Venolia, and R. DeLine [2006]
Motivation
• Can we create visualizations to helpdevelopers to externalize their mentalmodels?– How and why do developers use visual
representations of their code?
Research designA- survey of MS devs
350 respondents
B- interviews
9 interviewees
9 scenarios
C- survey of MS devs
430 respondents
Understanding existing codeDevelopers examined the source code and its behaviorin order to develop an understanding of it.
> I remember this one time where Iwanted to quickly see theinheritance of a bunch of classes.So I quickly created a diagram withthe Object Browser feature ofVisual Studio and then I threw itaway. [Colin]
- diagrams not particularly important- paper-based sketches- least concerned with accuracy
Ad-hoc meetingWhen a developer reached an impasse while trying tounderstand existing code or needed to vet a design decisionwith a teammate, he would walk to another developer’s office,interrupt her, and then have a brief discussion
> When I need to explain toa colleague how some stuffworks then I use thewhiteboard. [Nigel]
- sketches predominant- low concern for accuracy- same drawings reiterated frequently
Designing/refactoringEngineers planned how to implement new functionality,fix a bug, or make the structure better match its existingfunctionality
> I look at the diagram and if I seelots of fields in a certain table I seethat is a potential candidate forrestructuring. Or maybe I have asmall table with lots of jointconnections out of it. The diagramhelps identify design problems.[Daniel]
- visual to-do list- paper-based sketches
Design reviewTo evaluate a proposed design change, engineersperformed a design review to inform and seek inputfrom the affected people. Diagrams were often used.
> We did go through differentmeetings to understand what iswhat we call the game and whatwe call the engine. We wanted tobe sure that the core was abstractenough and diagrams helped infiguring out where theseboundaries were. [Tom]
- reverse-engineering tools- engineering notebooks
OnboardingWhen a developer joined a team he apprenticed with amore senior developer to acquire a mental model of thecode.
> My manager used this diagram toexplain the code to me when I firststarted. Recently I realized that Iused kind of the same diagramto introduce a new hire to theproject. [Andrew]
- diagrams were crucial- least concerned with the accuracy
Explaining to secondary stakeholdersThere were many stakeholders beyond the coredevelopment team, including testers, project managers,and internal “consumers” of code. Engineers typicallycommunicated with these people through face-to-faceinformal meetings. Drawings were often used.
> I was implementing a new featureand I had to make a designdecision and I wanted my PM toapprove it. As it was complicated toexplain what I had in mind, Isketched it on paper. [Andrew]
- the rarest among the scenarios- drawings were most important
Explaining to customersEngineers were responsible for presenting the architectureor usage of the software to external customers.
> I had to use this diagram withcustomers, but the state diagramsthat we were using were toocomplicated so I had to simplify itfocusing on the individualcomponents. [Geremy]
- recorded lecture- high degree of formality- use of graphic standards
Hallway artTeam leaders sometimes tried to foster team awarenessof aspects of the architecture by displaying informationabout the code in the team’s space.
> When we do planning or specwriting, we come out with this kindof design. Then we dive intoimplementation. We refer to thesediagrams every now and then tocommunicate with the rest of theteam. [Colin]
- unimportant activity- performed with low frequency
Technical documentationEngineers created documents (text + diagrams) describingthe architecture, usage, or internals of the code forteammates, other internal customers, or external customers.
>We have many sectors, whichcontain a rigid number of servers.We wanted to change that forscalability issues and so I wasusing these diagrams to explain[to the sustained-engineeringgroup] the inner working of eachmachine and the proposedchange. [Geremy]
- very important activity- drawings played a crucial role- used reverse-engineering tools
Discussion
A. Developers used transient diagramsfor exploration activities
Diagrams are drawn to support communicationand are definitely secondary. The conversation
has value, the diagram does not.!
Discussion
A. Developers used transient diagramsfor exploration activities
B. Software engineers used diagrams tounderstand, to design and to communicate
C. Developers did not follow any graphicalstandard
D. We observed a limited adoption of drawingtools
Validity
> Our results are similar to Dekel [2005] study ofdevelopment teams at OOPLA DesignFest.
> May be different in other situations or organizations
Tool concept (1):Capture
Many design decisions aremade during one-to-onemeetings
Engineers might benefit fromrecording these events (thediagrams + the conversationin which it was created)
Tool concept (2):Integrating reverse-
engineering and sketchingIn their sketches engineers oftencombined aspects of the currentstate of the code with proposedchanges.
This need might be addressedby a tool that combinesreverse-engineering withsketching.
?
Tool concept (3):Levels of abstraction
Engineers need to understand both the microscopicdetails of the code and the macroscopic conceptualstructure. No current view conveys both levels ofabstraction simultaneously.
Summary> Software engineers create diagrams to support face-to-face communication
> Current drawing tools were not capable of supportingthis need because they did not help engineers externalizetheir mental models of code
> The role of diagrams in software development differsfrom other engineering disciplines
Can we create visualizations to help developers toexternalize their mental models?
–Maybe … but we need to be cautious!!
Extra slides
Acknowledgments
We would like to thank the VIBE team and the HIP team,at Microsoft Corporation, for their feedback. The firstauthor was an intern at Microsoft during the summer of2006.
Particularly we would like to thank Andrew Begel, JakobBiehl, Pierre Dillenbourg, Nicolas Nova, GuillaumeZufferey, Mark Meagher, and the anonymous reviewers fortheir valuable comments on the paper.
Drawing tool used by Scenario
Sketches were the predominant medium
Frequency of each Scenario
Transient sketches were part of the daily activities
Sketching Medium byScenario
Future work: Code MapsM. Cherubini, G. Venolia and R. deLine. Building an Ecologically-valid, Large-scale Diagram to Help Developers Stay Oriented inTheir Code. Paper submitted to IEEE Symposium on VisualLanguages and Human-Centric Computing (VL/HCC 2007). Coeurd'Alène, Idaho, USA, 23-27 September 2007.
Iterated Sketch example
Contacts
• Mauro Cherubini (EPFL)<mauro.cherubini @ epfl.ch>
• Gina Venolia (MSR)<gina.venolia @ microsoft.com>
• Rob DeLine (MSR)<rob.deline @ microsoft.com>
• Andy Ko (CMU)<ajk @ cs.cmu.edu>
Resulting Model