12.4. Twisted Communications As soon as a project has more than one person working on it, communication within the group becomes vital. By default, communication seems to occur in the slowest, most error-prone ways that it can. If there is some choice between two things, then both choices will usually be made within a project, sometimes at the same time! Everyone who has been frustrated by the bugs and extra work due to lack of common knowledge in a group suspects that improving communication within a project will improve the product. They're usually correct, but it's quite hard to improve poor communication right when it is happening. Some instances of twisted and tangled communication include:
Email arguments -
Email is fine for short discussions without interrupting the whole group, but it's very hard to resolve disagreements using only email. After a couple of back-and-forth emails, it can help if you reduce the number of recipients to the minimum and, if possible, go and talk to each other face to face, and then write the resulting decision down and send it out to tie up the email exchange. If you're getting annoyed by someone's email, don't use email to replyor at least wait five minutes before sending the mail. What you intended as a witty retort may seem like provocative noise when reread later.
Bug thrashing -
Changing the state of a bug from Open to Closed to Open to Closed because there's a disagreement about the bug, or when there is managerial pressure to resolve it, is no way to solve anything. It only demonstrates that the group is not communicating properly. One helpful resolution that is sometimes possible is to reclassify the bug as a feature request. Otherwise, talk and listen to each other.
Noise in commit messages -
"Fixed Paul's ugly code." "I hate this parser!" "Stupid customer request implemented against my better judgment." Such commit messages seem funny at the time or may temporarily relieve some frustration, but remember that the purpose of SCM tools is to store information for a long time. None of these messages will tell someone looking at the code two years from now why you bothered to change it at all; it's just noise to be ignored. Take a breath and write a message that you might want to find yourself reading a few months from now. Huge messages rarely get fully read either. If the message is that large, then add it to the project documentation elsewhere and refer to that file in the commit message.
Overly terse sentences -
Just as too much content can hinder communication, so can too little. Concise and clear is good; overly terse or silent is just incomplete and frustrating to the listeners. It can also, correctly or incorrectly, give the impression that you are not really participating in a group.
Offensive code comments -
Opinions are part of communication, and everyone expresses their opinions in different ways. Comments that seem fine in the context of a few beers can seem overly harsh when written down and read later by someone without the same alcoholic context. Making offensive comments about other companies can bite you when you want to sell the source code to someone else. Expletives are usually just noise in code comments, but if they reach customers (for example, in log messages), then extra work may be required of everyone to remove them later on. Just stick to the facts in your source code comments. The Linux kernel "swear count" graphs at http://www.vidarholen.net/contents/wordcount show how this phenomenon has decreased as GNU/Linux has matured.
Telephones -
Telephones at work are a terrible way for developers to communicate! They interrupt the focus that is necessary for writing good code, and they don't help you communicate particularly clearly with the other person. They interrupt everyone else around them with their noise, and there's not even a record of the conversation after you're done. People who listen to their messages on speakerphone still amaze me. Caller ID can help somewhat, as do turning down the ringer volume and making sure that your voicemail greeting suggests that the caller use email instead. Even with all the drawbacks of email, I think that it is far preferable to telephones in a development environment.
Paging systems -
I once worked in a company that used an overhead paging system with loudspeakers in the corridor ceilings to find people, to announce meetings, and for anything else that was considered sufficiently interesting to someone. These pages interrupted the useful work of an entire company dozens of times per day, truly a net loss to that company. The only interesting pages came when the CEO was annoyed at someone and snarled at them publicly to come to his office.
Those are plenty of reminders of what can go wrong with communicating with other people. Chapter 11 contains many ideas for how to improve the communication within a project. |
