The Mindset

The entire software development scene seems to be occupied with the issue of communication. And with a good reason. We in the software industry really do have a communication problem.

Many of the problems we encounter in software development projects can be traced back to communication problems. Software development is a people-oriented activity. Almost none of the tasks in a software development project is automated. Even activities that are automated depend heavily on communication. Take for example automated testing. Without good communication between test engineers and developers, the testing process will be futile.

The Temporal Axis of Communication

The current hype around the communication problem is focused mainly on immediate communication. Whiteboards, standup meetings, and “collaboration-enabled” workspaces, are all tools to improve communication between developers in the present. I don’t underestimate these means. I often see two members of the same team sitting in one room and still finding it hard to agree on some aspect of their current task. So any idea that can improve communication between developers is more than welcomed.

At the same time the communication problem has more levels to it. Immediate communication is only part of the problem. In reality, software products have a long life span. Improving the immediate communication between team members is one thing, but it won’t solve your communication problems for the long run.

Communication has a temporal axis. As time passes, communication becomes more difficult and less accurate. Now, it might sound like I am describing a problem you might have in a couple of years, long after the project will end. But this is not the case. The temporal aspects of the communication problem usually emerge even during the project.

Let’s say you and your team are making some design decision during the project. Being well-trained agile developers, you immediately update one of your whiteboards to reflect the new design decision. Everyone seems to be synchronized on the new design.

A few weeks later, your customer requests a change in one of his requirements. You gather the team to discuss the new request. An important part of the discussion is dedicated to the question: how the new request affects the current design. You have the entire design in front of you all over your whiteboards. You can fairly easily identify what parts of the design need to be changed to support the new feature. So being well-trained, you take your whiteboard eraser and a whiteboard marker and “implement” the change.

Here’s the problem. Do you really know what will be the effect of changing this part of the design? Maybe you do, and maybe you don’t. Your whiteboard sketches don’t really contain this information. They show only the design itself. They don’t tell the story behind it.

Maybe that small piece of design you changed was essential for some performance constraint. Maybe what you just deleted was an inherent part of some other feature. And maybe, just maybe this new addition to the design breaks some implicit assumption, which was inherent to the product. And maybe not.

Between you and your team members, someone might remember some important detail from behind the scenes of that design decision. But do you really want to trust that?

When you manage only your immediate communication needs, communication problems will come back to haunt you. It might take a week, a month, or a year, but it will happen. You have to look beyond immediate communication.

This does not mean you have to document every single aspect of every single decision in your project. But you should consider the impact each decision will have in the long run.

Being Prepared for the Future

No, I don’t look for long formal documents. Writing documents is not fun for me either (although this issue is, of course, context-sensitive as you might guess). There is a lot you can do to improve long-term communication without writing lengthy documents.

A Wiki, for example, can be a great platform for both short-term and long-term communication. The fact that anyone in the team can access it, and edit the information it contains, makes it a great collaboration platform. And as an important side effect, the information is there as long as anyone needs it.

I’ve already described a similar application of a Wiki in the previous Elements Of Communication post. The project dictionary is just one example of the implicit project knowledge you can (and should) document, but there is much more information to pass on between developers and to any future developer in the project.

Don’t expect a Wiki to solve all your communication problems. An average-sized project will probably have so much implicit information that a simple Wiki might just not be effective. But it is a good start. You always have to keep your fingers on the pulse. Always verify that the means of communication you are using is still effective.

Remember that information, and especially implicit information, has a tendency to fade over time. Do whatever you can to make it available for as many people who need it for as long as they need it. No matter how effective your immediate communication is, you should go the extra mile to improve it so it can serve as effective long-term communication as well.

This entry was posted on Saturday, July 1st, 2006 at 2:17 pm and is filed under Communication, Documentation. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.