Assumptions
-
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.
-
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.
-
I've dealt with that same situation quite a bit. Requirements gathering is the task it seems no one really wants to do, and unless it's strictly enforced, it's a nightmare. On the same note, I've had more then a few times where I've ended up completely refactoring a project because the end user didn't know what they wanted. A couple times because they outright refused suggestions I made as not what they needed. That is until they saw what they thought they needed, and complained it wasn't what they really needed :/
-
And then they want/need something different once you deliver it!
Part of it seems to be that users aren't sure of what the want and their desires change as they start to see something in front of them.
Part of it is they don't want to put in time planning; they want to see something and then alter it.
But it keeps us employed and busy
-
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.
-
Old Hand,
You describe the reason I prefer smaller companies.
My favorite part of my job is interfacing with the people who will use the program, learning how they work, and translating that to a program interface.
I guess I could become a Business Analyst, but I also enjoy actually doing the programming
-
Her name is loner. Old hand is a nickname given based on the number of posts the person wrote.
-
Teaching someone to troubleshoot is maybe impossible.
I believe that what some people refer to as "Wisdom" is just the ability to effectively assimilate all past experience, evaluate it, and using algorithms, choose the most likely outcome. All in about 0.5 seconds.
-
Yikes... same thing again today. I assumed our office would be closed because everybody live 30 miles away. I live right down the street, so I went in, and now I'm probably going to be stuck here, with everybody else...
And yeah... my first response is always "well, maybe somebody tripped over the cord... go see if it's alive."
-
In a way, I'm lucky. In my current position, I could do the jobs of most of the people I write applications for (In many cases, because I did the job for a couple days in order to write an application at some point). Understanding the end user's needs goes a long way. Managers, and Business Analysts do tend to get in the way, but they can server an important function when implimented properly (evaluate need, make initial contacts, and then put the end user in contact with the developer) But... that's a rare situation :/
- I agree that you have to get past assumptions to properly respond to a situation, but they can also be a good starting point. What would you say to this though? Am I arrogant to assume that the code I have written will work correctly? All to often somebody comes to me as the DBA in a devlopment team and says "the database is broken!" Well, 9/10 time it is not the database. However, in order to provide the best level of support possible, my response has to be "guilty until proven innocent." So, I embark upon some fact-finding and debugging to determine where the glitch is occurring - which is a good way to enhance my knowledge of our systems. (But you'd think they would eventually learn that I'm not the one to blame )
-
Troubleshooting has always been a black art to me. Interesting attitude for someone who has done it on some level for all of my working life. I used to be an auto mechanic, then a small engine mechanic. You'd never believe how the skills cross over to being a SQL DBA unless you'd been through it yourself.
Still, like the video card story, I come across situations where I 'know' the answer but I can't explain why I came to that solution immediately....hence seeing it as a black art.
Would that it were easy to teach. We'd all have a better time of it if only because we could get the help desk to route tickets correctly.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson -
The human mind is an amazing thing and in many ways puts even the biggest supercomputers to shame. If supercomputers could feel shame, that is.
I remember reading in a book called "Expert Systems" that no matter what the subject matter is, a rule of thumb is that a human being does not become an "expert" in anything in less than 10 years, and often much longer than that.
The people building Expert Systems need to interview/interrogate
a human expert in order to get out of him/her all the 'steps' needed to perform a certain task. This is not an easy thing to get out of a person, even when they really do know them all, and are willing to share them, just because we don't consciously think of all the 'steps' involved in, say, diagnosing a problem in a 40-foot-tall machine that makes soup for the Campbell Soup Company, which was one example described.So we often don't know what we know. Or we don't know all that we know. Or... well you get the idea. It just isn't easy to describe to someone else, let alone ourselves, how we "know" certain things.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply