The Effective CIO

Shaking The Mouse July 13, 2009

Back in the mid-80s, optical mice made their first appearance.  Unlike their roller-ball brethren, optical mice used light reflected off a special mouse pad to detect mouse movement.  They were cutting-edge and fun to play with.

In my research group, our Sun workstations used these optical mice.  One day, a sales rep was in our lab demonstrating some software package, when the mouse stopped responding.  Nonplussed, she held the mouse upside down, shook it, and resumed the demo.  Our slack-jawed stares caught her attention, and she explained how the mouse “got clogged” every now and then, and shaking it “cleared the mouse” and helped it work again.

Now, it was true that the Sun optical mouse driver did hang every so often, but it was due to a small input buffer being overrun with too many mouse events.  If you waited a few seconds, the buffer would drain and the mouse would recover, no shaking necessary.  This woman, however, believed that mouse was clogged and that shaking was required to fix it.  It clearly worked: every time she shook the mouse, it started working again.

Determining the root cause of a problem and applying the right solution is a crucial skill, whether you are debugging hardware or solving personnel issues.  Our brains are so desperate to correlate cause and effect that we are easily convinced that some action, no matter how odd, really can solve a problem.  Even worse, as soon as we find what seems to be the solution, we stop looking for the real problem.

In the case of the mouse, some simple analysis of what could actually clog a device with no moving parts might lead you to conclude that something other than shaking was at the heart of the solution.  For larger problems in more complicated systems, it can take weeks and months of digging to find the true root cause.  But if we do not find the real problem, we are doomed to experience it again, compounded with the frustration that our “solution” is somehow not working.  A technical problem is not fully solved until you can connect the dots from the very first event in the failure to the very last element of the repair.

People problems are far harder to debug.  Unlike computers, people are non-deterministic and prone to sudden erratic behavior.  For many issues, we may never know why someone really made a particular mistake or acted in a certain way.  In many cases, the behavior is not repeatable, so our solution cannot be fully tested.  Nonetheless, we are duty-bound to explore as many avenues as possible to make sure we understand why people act in certain ways and how our own behavior can affect others.

Technical or personal, it can be tempting to grab onto the first potential solution and stick with it.  It’s certainly easier than digging and digging to prove that you solved the problem.  But how many times are we left implementing bad ideas or half-baked systems because we didn’t dig as hard as we should have?  Are you really getting to the heart of every issue in your world, or are you just shaking the mouse?