Monkeys Know Best

http://www.safetycenter.navy.mil/Articles/a-m/monkeys.htm



The idea behind this article is that without communication, knowledge is lost. You say, "Duh!" I say "What are you doing about it? You say "Oh... ummm..."



Right.



So in the article, the monkeys soon find themselves doing an action without ever knowing the reason. What's to stop the next monkey from coming in and saying "You guys are stupid! I'm gonna just change this." Every developer has faced that situation, "What's this piece of code doing here? I'm going to change it!" and next thing you know you've got a bug in your product that got fixed a year ago (but not if you use unit tests to test your bug fixes and you run those unit tests every time you check in code!).

So you need to communicate the history of things. In code we can do it through comments, or unit tests as I suggest. But what about bigger decisions? Why'd we only go half way on this feature? Who don't we park in the spot next to the street? Why don't we come in to the office before 10AM? Maybe time got cut short because the market changed, maybe the street cleaner comes by on random days and Bob learned that the hard way, maybe if you come in before 10AM then your schedule doesn't overlap enough with the rest of the company to make you an effective developer (or maybe it overlaps too much and you can never get anything done).

So we have tools now that help us pass on knowledge. Some are software tools like a Wiki, or a version controlled document management system (which might be the definition of a Wiki) that help us with history that someone might search for. Stuff you don't expect people to remember the details of. We also have other tools that help us transfer knowledge so that we can go on vacation and know that our feature is in good hands. "What kind of tool does that?!?!" you say?

Pair Programming is just such a tool. You sit, she sits. You write code, she writes code. You talk, she talks - and it's not all about code. You learn from each others' experiences, both code related and otherwise. You figure out how to better communicate with your boss, and you learn that you should always use a finally statement to clean up your objects that implement IDisposeable.

Meanwhile, you stay on task instead of checking your GMail, or http://fark.com, or to go vote at http://stackoverflow.com, or to wander around to talk to people... you are talking to someone already. So you're more productive, and when you get stuck, chances are that your partner is ready with a solution. It also gives you some added confidence, now you have two people who think the code is good instead of just one. You'll know that confidence is well placed the moment your partner asks you "Hey what about this edge case here?" and you go and write code to handle it.

It's not something that comes naturally. It's hard to give up your privacy, and have someone "sitting over your shoulder" all the time. But when you try it, when you do it, and you experience the difference, you'll never want to go back.