The Java Posse recently posted a podcast titled “Effective Communication” (it was a recording of a session of their “RoundUp” un-conference). I found it a fascinating discussion, all the more because it echoed many of the problems I’m experiencing right now.
Primarily, how do you get a group of developers to work effectively together? Communication is the key, and the way it happens can have a dramatic effect on the success of a project. To my mind, agile techniques such as pair programming, daily stand-ups and information radiators provide the best possible way to ensure knowledge and team culture is shared among all the members of the team. The podcast episode touched upon that, but they also spent a lot of time on various code review techniques and tools, which is another way to share knowledge (if done well). The show notes contain a lot of links to code review tools (Crucible being a crowd favourite – I must investigate).
The net effect of all these techniques is that communication is improved. The team can’t but help develop a shared understanding of coding standards, patterns, techniques, architecture, and so on. The team learns better how to work together. Risks of all sorts are harder to stay hidden because people are talking.
On the opposite end of the spectrum, I was recently asked to help develop a set of templates and checklists to help “improve quality”. I don’t hold much stock in code templates (especially in Java). Checklists can be very useful during design and review sessions, but the actual request was “Can we force the developer to answer this 41 question checklist every time they commit a change?”. My manager and I tried to explain the sheer amount of pain this would cause developers, without really improving quality. If there are problems with the development process, adding more beaurocracy to the process will rarely help. Improving communications channels always will.