“If It Worked Right The First Time – You Wouldn’t Learn Anything”

“If It Worked Right The First Time – You Wouldn’t Learn Anything”

. . . is one of my favorite sayings. Engineers who work with me tire of hearing it, but it’s a fact – you learn so much figuring out why something isn’t working. What makes good IT people tick is the desire to learn how and why things work. When things don’t work, there’s an opportunity to dig in, take apart, manipulate, put back together, and figure it out.

Our job at Beechglen is solving problems. Often the best way to solve problems is reproducing them in our lab. When you go through the effort of identically reproducing an environment and yet cannot reproduce the problem, you exclaim something rarely heard outside the walls of Beechglen – “Oh no, it worked!” – a corollary to my favorite saying.

Since 1988, we have been providing technical support and handling thousands of cases, from operating systems to hardware, RS232 to TCP/IP, operations to programming, we’ve honed many useful troubleshooting methods. One of the biggest lessons learned and incorporated into my tool-set came from a 12 year old. As part of a team developing a Windows front-end client-server application to an HP3000, we realized that we needed fresh blood to testing our application, so we turned to the son of someone on the team to test it out. Within 5 clicks the application crashed. “Why did you click there?” I wanted to ask. There was no reason to click there, no functionality to be gained. The answer of course, was because he didn’t know any better and simply because it was there to click. So we began testing absolutely everything and manipulating the application in ways it wasn’t intended.

Here is advice when it comes to troubleshooting: Manipulate the environment in ways you typically wouldn’t and determine what is working, and what isn’t. Feed the program other data or options it wasn’t expecting just to see what the other error messages arise. Try to connect to the server on a TCP port you know it isn’t listening on, or set it to connect to a bad IP address. Force other errors and compare those errors to the error you are trying to solve. Use these other errors to eliminate the problems you’ve just created from the possible causes. In other words, as long as you’re not at risk or causing more problems than you solve, don’t be afraid to color outside the lines.

Don’t get me wrong, I love it when things hum along and work perfectly – Then I get a chance to go ‘break’ something!