An IT Director’s Perspective on Troubleshooting

I am a big advocate of keeping things as simple as necessary. The old abbreviated adage, KISS (Keep it Simple, Stupid), still beats like a drum in my head after all these years managing and administering systems.

After having returned from 10 days of time away from work, I was able to gain perspective on a concept that appears simple, but is one we don’t always act on appropriately. This is the concept of flexible troubleshooting. (And as a brief side note, I cannot advocate enough the importance of taking a break from work every so often.) During my time away, I was able to completely unplug and let my brain focus on new challenges and puzzles, specifically, fly fishing in the Rockies of Colorado.

While I was off on my fishing expedition, which many would agree is not an overly complicated endeavor in itself, I found that on many occasions I came to a fork in the road that required that I make a decision that significantly affected my time and resources. This decision (or problem) manifested itself in the form of a knot in my fishing line. I have no idea how the physics of it play out, but when fly fishing, it is awful darn easy to get your line tangled in a monstrous and unforgiving “bird’s nest” of a knot. The decision I am faced with then is whether to attempt to fastidiously work out the knot, or to cut the line and start fresh with all new rigging. There are pros and cons to each, and each have a direct relationship on the amount of resources you expend or preserve.

Out of frustration (and compounded by the blazing heat, biting insects, and my general lack of patience), I often cut out the tangled mess and started fresh. This, however, turned out to be inefficient and wasteful. I neglected to acknowledge the amount of time I had already spent rigging up the now knotted setup, not to mention the cost of the materials I just threw away. So I then made the decision to make an attempt to untie every subsequent knot (which there were many). I quickly realized this was not necessarily the best approach either. At some point, attempting to work out an extremely tight and complicated knot has diminishing returns. In other words, the time it would take to figure out how to untie the knot far exceeds the amount of time if you started over from scratch. And factoring in my time investment (time = money, after all), one can argue there are appropriate times for hunkering down and attempting to work out the problem, as well as times where it makes more sense to start anew.

Over the course of my career in technology, I have faced many similar knots. When a PC gets infected by a virus, does it make more sense researching and attempting to clean the virus, or is it a better use of time and resources to just wipe the PC clean and reinstall everything from scratch? Or when dealing with a problem with our firewall where network packets were being reconstructed out of order, is the best solution to wipe the entire firewall configuration clean and start over, or do we take the time to engage tech support in an attempt to resolve the issue using the existing configuration?

Most issues in technology are not so cut and dry, and the path to resolution involves more than one fork. The key here is that when dealing with challenges (whether it be writing code, analyzing network protocols, or untying knots in my fishing line), it is important to remain flexible. At some point during your analysis of the issue, being flexible affords you the ability to gain the presence of mind to know which fork in the road to take. If you determine that working out the complication is the best path for your problem, start by attempting to resolve the issue in “bite-sized chunks.” For me this meant finding the end of my fishing line and painstakingly working it in reverse through all the twists and turns until the line was free. It is a slow and meticulous process that can preserve the resources you have already spent. And on the flip-side, if you determine it is more appropriate to start from scratch, don’t forget to factor in the resource investment that has already been committed.

My goal was to catch (and release) fish, and in the end I was successful because my flexible approach turned out to be not so complicated.

Mike Rasmussen is Director of Information Systems. He has been at Edmunds for 9 years and in the IT industry for 20 years. His current projects include overseeing the Edmunds upcoming office move, including the selection of a new corporate phone system and finding a corporate storage solution.

What drives us?

At Edmunds we’re not just about making car buying easier, we're also passionate about technology!

As with any website that has millions of unique visitors, it's a necessity that we maintain a scalable and highly-available infrastructure with reliable services.

We are excited by software design and strive to create engaging exper-iences while using coding practices that promote streamlined website production and experimentation. We embrace continuous delivery, dev ops, and are constantly improving our processes so we can stay lean and innovative. We also prioritize giving back to the community by providing open APIs for our auto-motive data and open sourcing projects whenever possible.

Recent Posts

  1. An IT Director’s Perspective on Troubleshooting
  2. Find Your Inspiration and Start Coding
  3. Being Agile in a ROWEnvironment
  4. Is Migrating to the Cloud a Financial Win for Your Company?
  5. Self-Governing Code - Using Static Analysis and Automated Testing to Eliminate Word-of-Mouth Standards
  6. The Unexpected Bonuses of Microbonuses
  7. Edmunds.com Expands Automotive Accelerator Program with Announcement of 2015
  8. Creating Innovation Paths at Edmunds
  9. Buying a Car is as Easy as a Conversation at Edmunds.com
  10. The Edmunds Revolution - One of Top 7 Best Technology Places to Work in LA
  11. Edmunds.com Updates Mobile Car Shopping App with Cutting-Edge Messaging Platform
  12. Academia and Industry Team Up to Give College Students Big Data during Annual DataFest Competition
  13. Building a Data Warehouse for Business Analytics using Spark SQL - Spark Summit 2015