After Hours

10 ways IT pros approach a problem

Forget the fancy problem-solving methodologies you learned in school. Here's how IT pros solve problems in the real world.

Quick: 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

Photo credit: Copyright ©iStockphoto/galdzer

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.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

116 comments
tommy
tommy

Very good. Made my morning. :o)

jpnagle59
jpnagle59

I learned what I know from a Co-Worker, who happened to become my best friends, let us call him 'J'...although he might not see it that way... In the 80's, I tried to break into electronics from being an Iron Worker. So, I teamed up as much as possible with the smartest guy I knew in the company...I would go along with him and watch all the pretty lights go off and on in the equipment he, the company worked with...the company developed a system to monitor banks here in Texas, and other locations across this great land of ours...almost at the end of the install, I was working with J on site, along with super tech's from across this land of ours...then, all the super tech's doing the install ran in to a snag, ie, the system did not work... there was a great gnashing of teeth...hair turned to grey...bodies sweated rivers of water...and the troubleshooting turned into a 4+ day event...I laid on the floor each night trying to grab some sleep while techs from far and wide banged their heads and sweated bullets...I kept asking what would happen if you pushed the BIG red button on the BIG thingy in the corner of the 'clean room' with all the pretty lights...I was told not to EVER touch that button...I kept telling them I just had to push that big red button... I just have to push that button...over and over that rang through my head...the techs left one night and went and took in food, water, and basic materials to keep their body's alive...I was left to guard the 'boat anchor' they thrived to bring up...meanwhile, over in the corner, on that big thingy with with the pretty lights, with the BIG red button, it started to call out to me...and it said...'...come push me....come push me...' So, I got up, did one of those theatrical looks over my shoulder, and pushed the BIG red button...everything went dead...the lights stopped lighting, the background humming silenced... and in my head I said...'oh, no, Lord help me now'... but the Gods listened to my cries... and thunder with lightning flashed, the wind blew strong, the Red Sea parted, and slowly- all the lights came on bright, and one after one all the remote locations came streaming in from all across Texas! ...time had stood still for me, but alas only 5 minutes had gone by......as the God like tech's came back and saw this miracle, they said---...to what Gods do we need to give thanks too- Apollo, Zeus, Thor, they asked this question of me... who do we give thanks too...?'... I told them It was I, the lowly Iron Worker!...as they then looked at me with disarray in their eyes...,I repeated with my cry-...'yes I did it'...what did you do they asked?...I said with pride,' I pushed that BIG old red button on that thingy in the corner! ...after seeing me in a new light, they gave thanks and praise, upon which they then bore me on heir shoulders and showered me we praise and glory ! and that is the story of my 1st trouble shooting maneuver...

JimTeach
JimTeach

This is so good I'm going to show this to my students. We go through all of the "real" methods of troubleshooting so I thought this would be a really good exercise to see how they react. We get so serious we sometimes forget to laugh at ourselves and our jobs.

leo8888
leo8888

This method always works well for me. I like to cross my arms, with my one hand on my chin. Stare at the monitor really hard and say "Yup, there's definitely something not right here". Turn off the monitor. Then go to Starbuck's for a peppermint latte. After that maybe stop for a candy bar or a donut. Then hop back in the car and crank the radio up. Oh wait, what was I supposed to be doing again? :-)

FaJitAS
FaJitAS

Step 1: I will allways first shout out: "Me lleva la chingada... " then slowly pronounce "ya se jodio". ("HELL!" + "sh%$t happens" may do the work). Step 2: Strike that [RETRY] button with a short prayer. Step 3:Go over to step 1 as necessary. You may practice all imprecations available at hand. With some luck this method will resolve the issue in the first cycle. After enough cycles... some wise idea may pop-up in your mind and you will now what is really happening, and more luckily, figure out how to really solve it! I DO really use this methodology. ;=)

PMPsicle
PMPsicle

Quick story for the young in the group ... Do you know why IT people call program errors bugs? In the very earliest days of computing, a programmer was running a program. He kept getting bad results. He'd review the code and everything looked right. He'd run the test at the end of the day and it would give one result. Then he'd run the test in the morning and it would give another result. So he'd go back and look at his code again. Obviously he'd made some type of mistake but he just couldn't find it. No matter what he did he'd get one result in the morning and another later in the day. Now this was back in the days of tubes so he finally decided it must have been a tube going bad. So he sent in the hardware guys to fix it. But that didn't work either. Problem finally resolved itself when someone noticed that there was a spider web on one of the tubes. Seems a spider would build his web every night when the computer was off. The tube would short and give bad results. After a while the heat would eventually burn up the web. So every night the spider would build his web again. Seems there was a bug in the computer. A sense of humour has been a key element in solving IT problems since the beginning. (And bug spray does help.)

mrmr98252
mrmr98252

I have been doing this a long time, and everyone will approach every problem a little different. If you have been doing this long enough, you will have a habit of going to the most common problem first. Then the second and the third. But even after 20 years of this, some times you are left looking like a monkey grinder. http://talentmechanic.files.wordpress.com/2011/03/monkey-grinder.jpg It is at this point no matter how good you think you are, you start with step 1 and work forward.

RMSx32767
RMSx32767

Which is different from solving a problem.

calbrit01
calbrit01

When you have illiminated the impossible, what ever is left, no matter how improbable, is the answer. [ for those who have to know the why, and for those of us who don't have time to worry about it]

mtnman28715
mtnman28715

We've all seen the IT Crowd right ... Have you tried turning it off and back on?

Elvis.GodZilla.777
Elvis.GodZilla.777

I work on cars (hobby) and computers (hobby)(living), and once in a while my wife is with me, and the person that I am helping just says "Wow, how did you do that", and she'll say "He just has that Swami touch". It cracks me up everytime :-) Sometimes it scares me. Sometimes I rely on it. SOMETIMES IT FAILS ME.

zeekobrown
zeekobrown

I really enjoyed reading this article as well as the different comments. For us IT pros, a little humour would surely help us keep the sanity and maintain composure in the face of anxious clients and impatient managers.

erikehlert
erikehlert

...I would love to see a comprehensive article that discusses troubleshooting methodologies that work for IT support teams. I have found that when a problem occurs, IT support takes a fairly haphazard approach to determining the root cause. That is, support teams don't follow any sort of troubleshooting process, much less a common approach. Most of us in IT are good at troubleshooting just because it's the way our brains are wired. So we can get by without lacking a common approach. Eventually, we seem to get to the root cause, but I think there's too much head thrashing and wasted time getting there. We need a better approach. One that leads us progressively through the troubleshooting discussions, results in documentation and decisions/remedies.

josmyth
josmyth

Sometimes the first thing to do is find out who reported the problem. That can tell you a lot about what might be wrong. I learned this when my dad got his first computer at age 70. Certain users have a talent for digging a deeper hole before asking for help. The real problem is by then masked by several layers secondary problems. "You did what? I didn't even know that was possible!"

eric
eric

None of the 10 are correct. The correct procedure is 1) Correct identify the problem. 2) Correct identification will tell you the solution, the risks, the outcome, choices for the client and recommended solution. If you can't do that you shouldn't be in the business. 3) Managed services should have alerted you to the issue before it became a problem. 4) If you can't work through problem logically - you are either in the wrong industry or your pay grade is too high for the skills you are supposed to have. 5) In any industry average skillset compentency is about 60%. In I.T. it is less than 30%. 6) 20 years ago in electronics service, you never heard a good technician saying "I can't fix it". You were armed with the correct docs (service manual), the correct tools (meters & scopes), and the correct training. 3 Years starting as an apprentice while studying, 6 years to become a professional. 7) Today someone does a six month course in computers and hey presto - they get an IPOD, a car, a laptop and they swann around giving business advice to unsusepcting customers. 8) On average your best competent programmers have at least 20 years experience, usually over 40, and have a business qualification of background. Apart from that - a good way to start the week with a bit of light comedy. Thanks.

Woodesigner
Woodesigner

I ran out of spare parts up in the graveyard years ago! Resort to finding thrown out junkers that the guys who repair and donate computers to the local schools have no use for. It's getting kind of hard to find Windows 95/98 era computers any more. No. Really! Replaced an NT server last year with an old boat that someone had set out for recycling at another company. Now the Comptroller reasons we should get another ten years out of that network!

rodaniels
rodaniels

...ok let me write that down ..I will get back to it after finals week

omg.itlead
omg.itlead

Offer to wipe out the system and reload. Watch the customer blanch with fear and say that the problem is not that bad, they'll live with it. The non-solution, solution.

brian_pam
brian_pam

Unplug it, and plug it back in...!!!

RaymondJM4
RaymondJM4

[ol][*] [b]Blame the user[/b] - Right from the word go, assume the user is WRONG! [ol][*] [b]Send me an Email[/b] - Avoid the porblem altogether! [ol][*] [b]Give it a second[/b] - Use the wait for me to finish doing nothing and see if it fixes itself! [ol][*] [b]Blame the last IT guy[/b] - Doesn't matter if there was no previous IT staff, just blame the last guy! [ol][*] [b]Research the problem[/b] - Leave the problem stewing while you research it on Netflix! [ol][*] [b]educated reboot[/b] - Say something technical justifying a reboot as an official fix. [ol][*] [b]Call support[/b] - Doesn't matter who you call, Just look technical holding the phone while you try to figure it out in your head! [ol][*] [b]visio Diagram it[/b] - This should take you until quiting time so you don't have to address the problem. [ol][*] [b]Requisition a New Network[/b] - Point out that this problem will persist until you get some new servers! [ol][*] [b]Setup a test lab[/b] - Doesn't matter that it was a printer out of papper, spend the rest of the day creating a test lab to reproduce the error. [/ol][/ol][/ol][/ol][/ol][/ol][/ol][/ol][/ol][/ol]

GSG
GSG

We tried #1. Several people were headbutting to no avail. Then, they tried #9, the Gatling Gun. Every single possible solution was tried. The problem is that there's no way to tell if one worked and was maybe cancelled out by another solution, so they had to go back and do it all again, one at a time. Finally, as an act of last desperation, they asked the 2 old-school folks who had worked with Windows NT and the network from hell at a previous employer. They explained the situation to us, and at the same time, we said, "It's the NIC settings. Bet it's set at auto-detect and not 100mbps/full duplex." Old School saved the day. I usually start with a little bit of Sheldon Cooper. Let's map the problem and figure out the top 5 things that could cause it. Then I go Old School, and if that doesn't work, then I go to the one that's not listed here.... The psychic. That's where I think about the problem, stew about it, then sleep on it. Sometime during the night, the amazing psychic super power kicks in, and I'll wake up suddenly and have it figured out.

zentross
zentross

Companies want results and are seeking to become more competitive (9,7, 5,1). The economy is still too rough for job hopping which forces extensive caution (8,3). I would definitely have to blame draconic micro-mismanagement for sarcasm that can be interpreted so literally.

bwallan
bwallan

No money for hardware BUT lots of cash for software they don't have the hardware to run...

colin.bruce
colin.bruce

Non one has mentioned Richard Feynman's problem solving algorithm: 1: Write down the problem. 2: Think real hard. 3: Write down the answer. I guess it worked for him:-)

tom_moore1986_gsy
tom_moore1986_gsy

1) move all client data to another hard disk, removable storage or SAN 2) [b]reformat[/b] the hard drive(s) 3) [b]install Linux[/b] 4) acquire source code for equivalent software, compile and install, going back to edit source code where necessary to bug-fix and uphold bespoke needs of your company/client 5) migrate user data back to hard drive(s) Done!

Mr. G. Anson
Mr. G. Anson

There is one way that ALWAYS works - K-T Problem Solving. I've used it many dozen times and it ALWAYS points to the cause and solution.

Ole88
Ole88

We all know that every homeowners toolbox needs only 2 things: WD-40 and Duck Tape (100MPH tape to us Vets). The IT toolbox has a 2 item setup too: a power cord and a hammer - plug it back in or beat it into submission. :) I like these joke articles!

PScottC
PScottC

Bring the dead system back to life with any spare components you can dig up from the computer graveyard. You know the graveyard... That room where you dump all your old equipment saying, "I'll send it to recycle next year". This tends to work extremely well for networks, since interoperability is fairly high. When a spare won't be available for a week or all your systems are out of warranty, this approach becomes more and more appealing.

muffle1969
muffle1969

I appreciated the article for its humor, and I also recognized that several of those methods are effective. :) Sometimes you just have to look at things from a business perspective. In my company's environment (storefronts with 1-2 PCs), time to getting up and running again is paramount. This means that many times, we employ the "restart" methodology, whether for the PC, router, modem, whatever. We track results, and if the issue recurs and we can't repair it with relatively quick troubleshooting, we switch out the suspect component. We have failsafes in place so there is no data loss, and the end user is back up fairly quickly. Once we get the suspect component back to corporate, we do further fault-isolation and troubleshooting in an effort to solve the issue, and add to our knowledge should we see the issue again. End users just want to do their tasks, and I had to learn long ago that it is not THEIR job to troubleshoot and fix; it is OURS. And I don't see the point in being snobby about it...it certainly doesn't solve anything.

gbcooper
gbcooper

11. The wait-it-out method......the problem might fix itself. You can later claim to have solved the problem remotely! 12. The Throw-everything-at-it-including-the-freebie-kitchen-sink approach....load it up with all the free registry fixer-uppers, defraggers, performance optimizers. then pray. then wait. if the user calls, tell them it's serious and will take a while. 13. The apply-your-mystical-dark-overlord-nobody-understands approach.....mumble incoherent phrases ans syllables while inspecting the user's workstation. say things like corrupt registry...missing a DLL.....IRQ conflict......etc. then take user's pac back to desk, blast with pressurized air, re-seat all socketed chips (if there are any), blow out all fans. plug it back in. and pray.

roobb
roobb

Way back in the old days, George Tom and I were debugging a serious problem that was taking the stock exchange offline every now and then. We had motivation to fix the problem! George said to "smell" the problem. After getting very agitated I realized George meant to commune with the system and use our detailed knowledge of the situation to ferret out a most likely cause through mental planning and deduction. Years later I continue to use this method and found over 25% of all the errors in a major NYC system that had 12 of us QA people actively working each day AND a team of 15 accountants testing the system as well. I guess intuition wins hand down.

BillDodd
BillDodd

Fix all of them with your gaze, ask who touched/used it last, wait until one of them flinches. Ask what they did, the tears will tell it all !! Theres you inroad to fixing the problem.

wompai
wompai

... the famous Gatling Gun often ends up in the Rip-It-Out-Start-All-Over.

arendsro
arendsro

Many years ago, we had a proprietary lab equipment server provide us with a problem that we just couldn't fix without potentially going through a huge amount of process and pain affecting some crucial operations. One of the staff used to collect all kinds of 'fun' items to keep around the office and just as a joke, we grabbed this rubber chicken, said a bunch of mumbo-jumbo and put the chicken on top of the server and kept it there. I'm not going to say that this worked but the problem actually went away and didn't come back...at least not with the usual symptoms. We never did find out what the issue was.

codepoke
codepoke

When the problem becomes bad enough, it will either be immediately obvious what the cause was all along, or they'll hire another firm to take the problem off your hands.

pgit
pgit

Depending on the problem you can do nothing and just declare the problem solved. It's the placebo effect. Anyone still complaining of trouble is a candidate for retraining.

NickNielsen
NickNielsen

Sometimes you just have to put the system out of your misery...

sysop-dr
sysop-dr

If something isn't working right, kick it. Works with Dogs, horses and computers (and the odd IT staffer-wait all IT staffers are odd.) Works especially with noisy CPU fans as one good kick will normally make them quiet down permanently. :-)

HENpp
HENpp

Very funny. This was a good way to start off the day. Thanks.

tjfelice
tjfelice

While the intent of the author may be to amuse the reader, as with most humor, the problem-solving approaches characterized in the article all have a grain of truth to them! One of the most helpful approaches to solving problems, as "thinkorthwim" pointed out, is identifying "what changed". ISOdx (www.isodxsolutions.com) is a forensic software tool that enables organizations (ISVs, OEMs, Internal Help Desks, Managed Service Providers) to resolve technology support problems faster than ever before by providing down-to-the-character insight into what changed on a device. Instead of reactively going back and forth with the end user to obtain information about the issue, ISOdx proactively provides all the forensic information required to resolve the issue directly to the support technician, eliminating the need to gather information from the end user. With ISOdx, the large majority of the most common support issues can be proactively sought out and communications to the end-user can be dispatched BEFORE they every encounter an issue. ISOdx can truly help transform the customer support paradigm.

grh
grh

...but more times than I care to remember users have been struggling to get their computer to work and call me; when I say OK be there in a couple of mins. I arrive and say 'What's the problem?' They say it won't do this and this and this but does that and that and that. I just touch the mouse (literally) and everything is fine. 'What did you do??!!' they gasp in amazement. I have no-idea but I don't tell them that, which is were jargon comes in handy. then I go off and think 'Hmmmm...what DID I do?' But who cares so long as the people are happy.

ptaylor129
ptaylor129

I have 30 years of experience in the IT Industry and have developed my own way to handle problems. I like to have FUN (Fear and Uncertainty in Networking) and use a technique I like to refer to as FWIUIW. Pronounced "Fwee' Wee" This translates to Futz (can be replaced with other expletive) With IT Until IT Works

Elvis.GodZilla.777
Elvis.GodZilla.777

Updates require reboots, though they should be written into the update, but I/T folk don't like to reboot without asking, but asking 2500 people every other day to reboot just gets old, so the occasional I/T call response is and should be "reboot" : - ) we had a batch of computers that needed to be physically unplugged every 30 days or so. this went on for years until the computers could be replaced. oh brother... that was no fun.

Tony Hopkinson
Tony Hopkinson

In my experience the bulk the industry is completely crap at it.

chris0sullivan
chris0sullivan

yeah....what more to say....guilty as charged!! :)

JCitizen
JCitizen

Post long jokes on Tech Republic instead of working, and tell the client you are emailing your "consultant". ROTFLOL!!! :^0

sslevine
sslevine

Too funny - I'm familiar with this one, too. We used to say the mumbo jumbo & shake the Tiki doll, and if no joy, would threaten the sacrifice and sprinkling of the blood of a chicken.