Wednesday, March 28, 2018

Principles of Good Communication: Hello World!

There are four principles for good communication (in relationships and systems networking).
  • Listen more than you speak.
  • Never assume that what you said is what was heard.
  • Agree on how you’re going to say things in advance.
  • Ask politely for clarification when messages aren’t clear.
Listen More than You Speak
The best way to maintain a good relationship is to be a good listener. Listening is more difficult than speaking. You can speak anytime you want, but since you never know when the other person is going to say something, you have to listen all the time. In networking terms, this means you should write your programs such that they’re listening for new messages most of the time, and sending messages only when necessary. It’s often easier to send out messages all the time rather than figure out when it’s appropriate, but that often causes problems. It usually doesn’t take a lot of work to limit your sending, and the benefits far outweigh the costs.

Never Assume
What you say is not always what the other person hears. Perhaps they misinterpreted you, or perhaps they just didn’t hear you clearly. If you assume that the message got through and continue on oblivious, you’re in for a world of hurt. Likewise, you may be inclined to first work out all the logic of your system - and all the steps of your messages before you start to connect things - then build it, and finally test it all at once. Avoid that temptation.

It’s good to plan the whole system out in advance, but build it and test it in small steps. Most of the errors that occur in these projects happen in the communication between objects. Always send a quick “Hello World!” message from one object to the others, and make sure that the message got there intact before you proceed to the more complex details. Keep that “Hello World!” example on hand for testing when communication fails.
Getting the message wrong isn’t the only misstep you can make. A common mistake people make when developing technical projects is to assume that the problems are all in one place. Don’t assume that communication errors are in the element of the system with which you are most familiar. They’re most often in the element with which you’re least familiar, and therefore avoiding. When you can’t get a message through, think about every link in the chain from the sender to the receiver, and check every one. Then check the links you overlooked.

Agree on How You Say Things
In good relationships, you develop a shared language based on shared experience. You learn the best ways to say things so that your partner will be most receptive, and you develop shorthand for expressing things that you repeat all the time. Good data communications also rely on shared ways of saying things, or protocols. Sometimes you can design a protocol for all the objects on your system, and other times you have to rely on existing ones. If you’re working on a previously established protocol, make sure you understand all the parts before you start trying to use it. If you have the luxury of making up your own protocol, make sure you’ve considered the needs of both the sender and the receiver. For example, you might decide to use a protocol that’s easy to program on your web server but turns out to be impossible to handle on your microcontroller. A little thought to the strengths and weaknesses on both sides of the transmission will make things flow much more smoothly.

Ask Politely for Clarification
Messages get garbled in countless ways. Perhaps you hear something that may not make much sense, but you act on it, only to find out that your partner said something entirely different from what you thought. It’s always best to ask nicely for clarification to avoid making a stupid mistake. Likewise, in network communications, it’s wise to check that any messages you receive make sense. When they don’t, ask for a repeat transmission. It’s also wise to check, rather than assume, that a message was sent. Saying nothing can be worse than saying something wrong. Minor problems can become major when no one speaks up to acknowledge that there’s an issue. The same thing can occur in network communications. One device may wait forever for a message for a message from the other side, not knowing, for example, that the remote device is unplugged. When you don’t receive a response, send another message. Don’t resend it too often, and give the other party time to reply. Acknowledging messages may seem like a luxury, but it can save a whole lot of time and energy when you’re building a complex system.

No comments:

Post a Comment