It takes more than a few fireside chats to get everyone on track
This week we went beyond the code to take a human perspective on software engineering. After the introduction, we touched on team building, and methodology. Today we continue on to cover communication and documentation. They go hand in hand, documentation being a form of communication, and are the culmination of the human aspects of software engineering. In my experience, having an established methodology facilitates them both. I had the pleasure of helping a team adopt Scrum as they grew in size. It was quite an adventure, but one of the things I noticed is that once everyone was on the same page for process, communication flowed more naturally and in greater volume. In The Mythical Man-Month, Frederick Brooks discusses communication at length, and how the cost of communication grows exponentially with the size of a team. However, he writes to us from the 70's. Today we have a slew of modern tools that help cut the cost of communication: cell phones, instant messaging, email, video conferencing, and my all-time favorite: the wiki. Personally, I like to use a combination of verbose in-line comments and a good wiki to help tackle both communication and documentation. That's just me. I take lots of notes in a text editor every day. As my notes files grow, I organize them and find where they belong in the wiki.
Other members of the team can then get a good understanding of my work by looking at my code or reading the wiki. Later, the wiki becomes an excellent source from which formal documents can be created. However, I know of teams that use Skype exclusively. Still others use various IM protocols and email attachments. And I had good success with Google Docs at a couple of organizations in the past. I'm going to conclude my blog series for the week by opening up the discussion. How do you and your teams communicate? What kind of documentation during the development process helps you write the best software? Is it better to narrow the communication channels to a small set of tools and impose them on the team, or is it best to let everyone loose to use the tools of their choice? Are Brooks' observations about the cost of communication overhead still applicable today, or have modern tools invalidated his formulae?