We had another snow storm in Denver this weekend. We woke up Saturday morning to howling winds and a near whiteout. We could barely make out the house next door or the truck parked up on the road about 1/4 mile away. It was early, but we were thinking it would be a quiet day at home.
Assumption #1: I was sure my son's basketball game would be cancelled, but since it was the last game, I called the league. To my surprise the games were still on. Fortunately he had a 12:00 game, so I had plenty of time to plow the driveway.
Assumption #2: When we woke up, we wanted to check the weather, but our Internet connection was down. We assumed the howling wind, still a good 30-40MPH, had knocked things out, so we went to a backup plan: we checked the local TV news, something we haven't done in years, and I made plans to go to Starbucks that afternoon to work on newsletters (and editorials). About 2:00 in the afternoon we still weren't up and called the DSL provider. After learning that they'd changed our username and password for the router, we got things sorted out and were connected again. Glad we called!
Assumption #3: After having our yard and road covered in snow, I was pretty sure that my first baseball practice would be put off another week. I slept in and almost as an afterthought called the coach at 9. I learned that people that wanted to play were going to practice, so I scrambled to get out the door and to practice by 10. It ended up being a great day and I'm glad I called and didn't stick with my assumption.
In the IT world we often have our viewpoints clouded by recent events. We expect something and end up looking for it as the cause or reason that something occurred. Often this serves us well and allows us to quickly hone in on problems, especially if we have a feel for the system.
But when that doesn't work, even the best of us have trouble stepping back and discarding our assumptions, or at least checking to be sure that they are valid.
Teaching someone to troubleshoot and how to look at a problem is hard. It's almost something of a knack that you have or don't. Which seems crazy because you'd think we could make a list of steps to follow. We could, but with even a moderately complex system we'd end up with 78,426 steps, the first 4 or 5 of which would be to check power cords and be sure things are plugged in. And people would quickly start skipping steps and we'd be back where we are.
Maybe that's why we're here.
Follow me on Twitter: @way0utwestForum Etiquette: How to post data/code on a forum to get the best help
At one place where I worked, there were two servers that controlled RF communications. A primary, and a backup. No one ever thought about them because, well, they just worked, and had for years. One day, I needed to get into the servers to make a change, I hook up a monitor to the first one, and get the job done, then I move on to the backup server. except, it's not on. It turns out that a few years back, our network admin who worked in the server room had turned off the computer because it started beeping, and he couldn't figure out what was wrong, or how to fix it. Since no one complained, he decided the computer couldn't have been that important, so he just left turned off on the rack.
So, here's where the knack for trouble shooting comes in. I call in our new network admin to help troubleshoot the problem. We hook up the server, plug everything in, and hit the power button. Nothing happens except a series of beeps. I look at the network admin, and say "The video card's fried". His response is along the lines of "how do you know that" I spend the next several min trying to explain my reasoning, and fail miserably. He insists on a long drawn out attempt at a bunch of other things, until I convince him to track down a compatable video card. we plug it in, and the computer boots without a hitch... well, almost... the card isn't compatable with the OS/2 draver that's loaded, so we can't do much... We ended up finding another card with a similar chipset that would run on the same driver, and the server's back up, but, it goes to show... some of us speak beep, others may know how to troubleshoot, but have absolutely no instinct as to where to start.
assumptions can be a great starting point when you're troubleshooting... as long as you're willing to let them go if they don't pan out.
Assumptions, my biggest bane as a developer...
I work in an environment where requirements gathering is not a very high priority. The users really don't want to give you the time and management doesn't care because requirements gathering keeps folks from their tasks. As a developer you are expected to be the SME. It is really a drag. Having assumptions in an environment like this is a way of live and they cause a lot of extra work.
Most days I'm busy enough without needing to redo something 10x
When I worked in a small company, I had to talk to the users and collect requirements. They had no problem telling me what they wanted. All my projects were finished in time and the users were happy.
In most big companies I worked for, the business analysts supposed to talk to the users and gather informations. Then they wrote the function spec or the scope of the project to the IT department and the developers developed the project. 9 out of 10 times the scope or the requirement was wrong. We (the developers) spents all the time working on something that no one wanted, or when we got the scope/requirement, we found out we did not have the resources or it could not be finished before the deadline.
What was the problem? The business analysts !!!!! They did not ask the right questions and they did not understand the current system. Basically they did not understand the business and they did not understand the system. Sometimes I don't even know why they were there. I worked with many business analysts, maybe 1 out of 1000 could be able to do the right job.
I asked my manager many times why I could not talk to the users myself and he said it was the company policy and it was not part of my job.