Extra pair of eyes

"If you were given an extra pair of eyes, where would you like them to be?" This was the question Fredrik Haren, author of the idea book asked the audience. Almost all replied instantaneously, "At the back of my head!" This sounded like the best answer, as then one could look in all directions without having to turn around. "This is probably the worst answer," said the author.

By the way this was on Feb 9, 2009 at Kuala Lumpur where Fredrik was the keynote speaker at PMI Asia-Pacific Global Congress. I would not go into details of what else he said as I have already discussed that in an earlier blog. However, if I was given a choice to choose where I would like this extra pair of eyes, I would say "on the person next to me." I do not see much use of this extra pair of eyes when my brain is not capable of processing two different views at the same time. I do not mind turning my head for another view, as I do not want to mess my brains up.

If the two eyes came with the brain too, that would change the situation. If the two eyes and brain came with rest of the body parts and everything that makes a person, that would be perfect. Yes, there was an easy way to say all this, I need another person, but the story says something more than that. It says that the two persons would still be working on the same task. Contrary to the hypothetical scenario where we expect two pairs of eyes to look at two different views, here the situation is realistic and needs two pairs of eyes and the two brains behind them look at the same view from two perspectives. That would give us something closely resembling a 3d view.

Much earlier in my career I worked for a company for fifteen days when I was between jobs. On the first day the company was faced with a situation where we had to decide in a minute whether we would take up the job of digitizing a few thousand key-value pairs from handwritten hard copies. We could refuse the job but if we accepted we had to deliver the soft copy in six hours with absolutely no mistakes. My bosses were not even discussing it as they were pretty sure the target was out of reach. They were particularly scared of errors that would have landed us into trouble. However, on my insistence they decided to give me a chance.

It was 4 pm in India and we were required to deliver by 10 pm Indian time, an hour before our counterparts in US were supposed to demonstrate a particular solution. It was a simple, clear cut, well defined and a pretty critical job. I, first of all, assembled the whole team and explained to them how important the task was for us and how it could shape their careers. In just a few minutes I got 20 volunteers who were willing to stay back till 10pm and were well motivated and energized. Instead of splitting the data into twenty I paired up the team and distributed the sheets among 10 teams. The target given to them was 9 pm but I received all 10 files before 9. Then I interchanged the files between teams and they once again verified each other's work. It took me hardly 10 minutes in the end to combine the 10 excel worksheets into one and the file was sent by email before 9:45.

Next morning we had a friendly chat session with the management and it was acknowledged by all that the best thing that we had done was working in pairs. In a way we used only 10 people with an extra pair of eyes for each and the value we got in return was much more than just 20 pairs of eyes. Probably this is what happens in extreme programming.

Basically when we do a code review or even otherwise analyze the root cause of bugs going into the code, we realize that most of the bugs are not due to inability but due to oversight. My experience as programmer has also taught me that it is more time consuming to detect and fix an issue if it is small and difficult to reproduce. Generally such issues are detected much later and cost an arm and a leg in terms of money and somewhat similar in terms of time. Sometimes it is just a typing mistake, where a programmer thinks something but his fingers have typed something else and sometimes a programmer just overlooks a reasonably evident potential issue. Even in the unit testing most of the defects that a programmer detects are very simple mistakes. Most of the times when we write a piece of code, it does not even compile for the first time. We discover that we have missed a semicolon somewhere, we have also missed to import some class and we have missed to declare some method correctly. Very small and simple mistakes that we fix in less than a minute. We compile again and it works. But what about other such small mistakes that the compiler does not tell us about?

Before I move on I would like to sincerely apologize to the non technical people as there was no way I could have explained my next point with simpler language.

Suppose we are required to code a java method that updates the last name of a member. The programmer writes the query in two lines appending the second to the first and both are inside a try-catch block.

String query = null;
Try
{
query = "UPDATE ACCOUNT_TABLE SET LASTNAME = " + newName;
....... some code .........
query += " WHERE MEMBERID LIKE " + memberID;
}
Catch (exception exp)
{
//do nothing
}
updateQuery(query);

I suppose most of you already know what is wrong with the above code, but for those who do not, let me tell you what it is. This is a perfect recipe for disaster. This method will be called hundreds of times every day if the website has millions of users and there are good chances that due to whatever reason on some value of memberID an exception will be thrown or there might be an exception thrown due to a bug in the code between line one and two. With the result the second part will not be appended and the query that is executed will change the last name of all the users, probably millions of users to the new name. What are the chances that a programmer will write the code as above without realizing what's wrong? It will be a small and simple mistake with catastrophic impact. The recovery will be somewhere between very difficult and next to impossible if not detected within a few hours, unless there is a backup.

An extra pair of eyes makes it almost impossible for a programmer to make such mistakes.

An extra pair of eyes can also be a savior in management. Often the c-Suite executives face the challenge of being lone decision makers. They find lot of people who nod their heads in affirmation of whatever they do or say but very few to show them the reality. This is not just done by the reports to get themselves in good books but also by the friends and family. The impact is again often catastrophic. Few years back one of my friends who was the CEO of a well established company came up with some weird idea. He wanted to build a product that did not seem to have a good revenue model. The problem was that, even though being an MBA from a reputed university in US, he thought less about the risks and was more interested in listening to his friends who told him:
"What a wonderful idea!"
"Nobody has done this before, you will be the first."
"People are going to love it."
"That is so innovative."

Nobody told him that since he was making a loss per piece, the more he sold more he would loose. It was just not an idea worth considering but he was able to see it from a single perspective and from that perspective it looked wonderful. Had somebody shown him the reality, he would still be the CEO and more important the company would still be functioning. This is precisely the reason many management gurus advocate employing a mentor, an advisor, a coach or a consultant (whatever the name). It is definitely not because the extra help is better in any way but only to show the reality as and when required.

The extra pair of eyes can do wonders.