Deliberate practice, effective sketches
Creating a collection of simple diagrams to communicate your vision
In Where are the software architects of tomorrow?, I talked about how most software developers don't get to take a blank sheet of paper and design software from scratch all that frequently. Related to this is the process of communicating those designs, either during (e.g. when collaborating) or after (e.g. when documenting) the architecture process. In concert with just enough architecture, my preference is for effective sketching rather than comprehensive UML models.
An initial set of sketches
Back at the start of March, I ran a tutorial at the QCon London 2011 conference entitled "Designing software, drawing pictures". After a short presentation to ensure a common starting point, everybody that came along was split into small groups and asked to design a software system given a brief set of requirements. Pretty much no guidance was given to the groups other than "choose some technology, design some software and draw some pictures to portray your vision". Here are the sort of pictures that were drawn.
You've probably seen pictures like this before. They're okay if you're explaining while you're drawing but they tend to show too much detail, mix abstractions and leave some things to your imagination.
A second attempt
To counter this, I tend to use a collection of simple diagrams, each of which focusses on a specific level of abstraction ... context, containers, components and classes. Back to the QCon tutorial and, after some additional guidance, the groups were asked to revise their diagrams. A short amount of time later and here are the sort of pictures created second time around.
Much better! Even without knowing anything about the software being designed the pictures look simpler, less cluttered and clearer. When you do know something about the software though, the new pictures allow you to get a feel for what's going on and understand the vision behind the design much more easily because each picture only shows a single level of abstraction.
You can see some more photos at http://www.codingthearchitecture.com/presentations/qconlondon2011-designing-software-drawing-pictures/ and chapter 3 of our book provides more information on the type of pictures that I draw. If you want to practice drawing effective sketches yourself, I'll be running a similar session at the GOTO conference in Copenhagen and we cover it on our Software Architecture for Developers training course.
Re: Deliberate practice, effective sketches
Re: Deliberate practice, effective sketches
There's no "right" answer, but most of my context diagrams tend to exclude technology and are diagrams that anybody can understand, even if they know nothing about the technical nitty gritty of software development. That's what the containers diagram is for.
