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.
A lot of people have pointed out that formal diagrammatic notations for software, like UML, are taught much more often than they're used. This paper goes a long way toward explaining the reason: in almost all cases, developers use diagrams as a way of keeping track of bits of conversation while talking to each other, rather than as archival documentation for the benefit of people who weren't there at the time, and the cost of turning the first into the second is so great that almost no-one ever does it voluntarily. As well as explaining one aspect of real-world software development, this paper is also a great example of how qualitative methods can produce answers that quantitative investigation never could.
Originally posted at Never Work in Theory.