10 ways IT pros approach a problem

 

How many ways can you approach a problem? Oh, I’m sure the school of business you attended had plenty of businesslike names for the various approaches. I’m also betting that those approaches are so deeply steeped in academia they have little bearing on reality. (You know — the reality that smacks you upside the face on a daily basis with a Cat5 cable? Yeah, that one.)

So instead of trying to list the pedantic problem-solving paths that are available, I decided to list some of the real-world approaches many field engineers and IT admins take, which wind up (ideally) actually providing a solution.

1: The Headbutt

There are engineers out there who will do this. A problem arises and the gentle, effortless touch simply will not do. So instead of playing nice with the issue, this approach demands the engineer land powerful blow after powerful blow to overcome the obstacle. You know: taskkill, reboot, hard shutdown… the tools of the hamfisted administrator in desperate need of anger management. But you know what? We’ve all reached this point with a problem and felt like the only possible solution would be born of desperate measures. That is The Headbutt. You bang your head against the monitor long enough and something brilliant (or fortuitous) will occur.

2: The Elmer Fudd Stealth Attack

Tiptoe. Shhh. Be vewy quiet. I’m hunting down a pwoblem and I’m afwaid if I’m too loud, it will run off before I fix it! You know this one. It’s that Exchange box that’s been giving you fits, but you are afraid to touch it the wrong way lest it go belly up and you’ll lose years of user email. So you proceed with Monk-like caution, tapping out commands as if each touch of the key will cross the streams and bring down every system on the planet.

3: The Sheldon Cooper Labyrinth

You know who I’m talking about and you know exactly how this plays out. You have a problem… and you have a whiteboard. On that whiteboard, you map out every possible path to a solution that you can imagine. Each path also has branching paths that turn the solutions into a veritable Einstein mind map. This approach becomes so convoluted it requires a degree in quantum mechanics just to unravel the string of solutions presented to the engineer. In the end, this approach fails because by the time a solution has been reached, the system has died its final death.

4 The Ninja Strike

Although some planning goes into this approach, it’s mostly all about stealth. Sneak up on the opponent so that it has no idea what hit it. That server won’t have time to react to the command before you’re already on your way to the next task. Generally speaking, The Ninja Strike is an approach best used when you know a problem is elusive and will avoid showing itself if it knows you are coming.

5: The Rip-It-Out-Start-All-Over Approach

This method is drastic, but sometimes necessary. When a problem reaches critical mass, where continued troubleshooting is going to cause more work than simply starting all over — you start all over. Pull the plug. Rip it all out. Sometimes starting from scratch is the only feasible solution. But I say this with one warning: Please make sure you have a solid backup before you start afresh.

6: The Old School Methodology

Ah, the command line. There are those of us who’d much rather do things by the command line than by the GUI. And many times, problems can be completely averted or resolved that way. This is especially true when managing a Linux or UNIX box, where the command line is king and can and will help you out of sticky situations. Thing is, not everyone is comfortable with the command line. Fortunately, The Old School Methodology isn’t limited to the command line. The entire approach can be seen with an eye to older solutions. For example, instead of the one server to serve them all, the old school approach will separate those services onto different machines! Gasp! What, no virtualization?

7: The Squeezing-Blood-from-a-Turnip Trick

What happens when you have a client refusing to spend the necessary cash on the hardware they need to actually run their business? You’re stuck trying to get hardware to do more than it should — squeezing blood from a turnip. Most often, this causes administrators and engineers to search for creative solutions, which often winds up with a server hosting too many services. That, of course, is where a two-pronged approach comes in handy. The two prongs: Squeezing Blood from a Turnip and Old School.

8: The Paranoia-It-Will-Destroy-Ya Trap

You know you’re afraid to do what you have to do. The second you reboot that server, it’s not going to come back up. The minute you unmount those exchange stores, they won’t remount. That backup you created? It won’t restore. And even when you throw everything at the problem (including the kitchen sync) nothing will fix it. With this approach, each step along the way will have you second-guessing yourself, growing increasingly tentative, and turning grayer by the moment.

9: The Gatling Gun

Throw. Everything. At. The. Task. And. Something. Will. Eventually. Work. You know the approach. You start with the simple and work your way up to the complex and at some point the problem will just vanish. This is probably the most popular approach, as most problems don’t ever seem to want to resolve themselves with the first and easiest fix.

10: The Sloth Routine

And now, the most unpopular approach when seen through the eyes of the client. This approach is generally used for two reasons: 1) The client has more money than they know what to do with and 2) The engineer has no idea how to solve the problem. So when this method is employed, the solution is way off on the horizon and the problem solver is in no hurry.

Which approach is best?

Which method do you embrace? Do you use a combination of these techniques? Are these the same problem-solving approaches you were taught in college? Sound off in the comments. Let us all know how you work and what works best for you and your clients and/or users.

Thanks & regards,

"Remember Me When You Raise Your Hand For Dua"
Raheel Ahmed Khan
System Engineer
send2raheel@yahoo.com
send2raheel@engineer.com
sirraheel@gmail.com
send2raheel (skype id)

http://raheel-mydreamz.blogspot.com/
http://raheeldreamz.wordpress.com/
http://www.facebook.com/pages/My-Dreamz-Rebiuld-our-nation/176215539101271   
http://www.facebook.com/pages/Beauty-of-islam/223983470988333?sk=wall               
http://www.facebook.com/pages/Health-is-wealth/289486761065829?sk=wall