This is part of a series on “I believe in…”
Early on in my work as a software developer, it became clear to me that communication was one of the biggest barriers for a team to create something valuable. Communication comes in so many different forms (many of which I believe have been unfairly maligned), and as a developer, I wanted to understand each of them and leverage them to their greatest potential. I read The Mythical Man-Month by Frederick P. Brooks, Jr. and was flabbergasted at the amount of communication that went into the OS/360 project that he references through the book. Looking at the small team of developers that I worked with, the level of communication Brooks wrote about seemed crazy. Yet, it resonated with me.
So, I tried to get my team on-board with more communication. We had tools for communicating, but they weren’t really used. For the most part, we took a stack of ideas written in a Word doc from our boss (who played the role of a product manager) and then we huddled together to divvy up the work, only coming together again to discuss the interfaces between one person’s work and the other, and mostly after the work was already “done.” Bugzilla was a joke, the fancy tools we had from Microsoft and Rational Rose were haphazardly used, if at all, and testing, let alone test plans, were almost non-existent.
I was determined to “lead by example,” creating documentation to spur my colleagues into communicating more. My reasoning was: if I created these artifacts to share, shared them, then brought us together in meetings to discuss, then we would improve communication. Right? I was going to validate my specs and designs with peers before I built the wrong thing, and I was going to have us work more as a team.
I wrote specs. I made Use Case Diagrams. And Sequence Diagrams. And Entity Relationship Diagrams. I setup a list-serv for the team. I tweaked VSS to require commit comments of a certain length. I added fields to Bugzilla to capture more detail. I even tried to make Gantt charts to show the dependencies we had between each other over time.
And maybe we worked better as a team. Maybe not. This was early in my career, and it’s hard to say if the communication I tried to foster made a difference to others, or to our output. And, this was 20 years ago, so my memory may be a little hazy.
And, learning that “communication is important for teams” isn’t really a ground-breaking discovery.
What I did learn was that writing it down, drawing it, diagramming it – those activities were more valuable than I ever thought. It brought awareness to problems I had not yet perceived, and forced me to move from my abstract mental visualization of a solution into something more concrete. Spending 15 minutes trying to translate my ideas into something constrained by a whiteboard’s two-dimensionality and only 4 marker colors actually helped me solve problems better and faster.
And it didn’t matter if anyone ever saw those diagrams or not. The value was in practicing the translation of an abstract idea into something concrete, with all of the physical constraints that that concrete form imposes.
Only when one writes do the gaps appear and the inconsistencies protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact [ideas] from fuzzy ones.The Mythical Man-Month – Frederick P. Brooks, Jr.
Neuroscience is not something I really know anything about. But, maybe it is similar to what Betty Edwards found and shared with us in Drawing on the Right Side of the Brain. Maybe that simple act of forcing both hemispheres of your brain to try to solve a problem helps software developers and engineers build the right thing faster.
Lastly, my belief in writing and drawing does not apply to just software development. Any process, any system, any organization, any abstract concept can be better known to you by trying to turn it into language or an image.
I believe in writing things down. I believe in drawing and diagramming as a tool to develop a better understanding. An audience is not required to make this act valuable. The more abstract the “thing” is (like software architecture – it is much more abstract than, say, the framing of a house), the more value there is in diagramming it.