As a coder, it is easy to approach problems in a haphazard way. Sometimes, when we encouter a bug in a piece of code we're working on, we use a trial-and-error method to attempt to shoo the bug away. But as Brian described in a recent blog, good troubleshooting should follow the scientific method.

For simple problems, it may be possible to hunt-and-peck through inputs and scenarios until we see the results we expect. But for complex issues, trial-and-error will usually be inefficient. And more importantly, when troubleshooting issues in a production LIMS environment it is rarely even possible to perform trial-and-error tests. Unless we are fortunate enough to have the production environment replicated to a testing platform, we are forced to use a more scientific method.

And this is exactly where I found myself recently. While troubleshooting issues in a production LIMS system, I was forced to think through the problems and develop solutions without performing any actions that would modify the state of the system. I walked away from that troubleshooting session with a very clear understanding of the issues and the neccessary solutions. Although I had been through experiences like this many times before, this time it dawned on me just how superior this approach was to the trial-and-error techniques I would have been using had this been a development system.

A scientific troubleshooting technique may take a little extra time up front, but it will usually save time in the long run and will give the troubleshooter a more complete understanding of how a system works. Although not always the easist path forward, troubleshooting issues in a scientific manner really pays off. I, for one, need to become disciplined enough to use the technique all the time, not just when forced into it by circumstance.