Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Assumptions Expand / Collapse
Author
Message
Posted Tuesday, February 27, 2007 5:24 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: 2 days ago @ 3:49 PM
Points: 31,161, Visits: 15,607
Shrek Donkey


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.

Post #347996
Posted Wednesday, February 28, 2007 7:47 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, October 9, 2007 10:12 AM
Points: 818, Visits: 10

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.

Post #348121
Posted Wednesday, February 28, 2007 8:06 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, October 13, 2014 11:50 AM
Points: 55, Visits: 233

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.

Post #348135
Posted Wednesday, February 28, 2007 8:18 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, October 9, 2007 10:12 AM
Points: 818, Visits: 10
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 :/ 
Post #348143
Posted Wednesday, February 28, 2007 8:51 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: 2 days ago @ 3:49 PM
Points: 31,161, Visits: 15,607
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







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #348157
Posted Wednesday, February 28, 2007 9:02 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, October 9, 2007 10:12 AM
Points: 818, Visits: 10

Most days I'm busy enough without needing to redo something 10x

Post #348161
Posted Wednesday, February 28, 2007 9:41 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, October 9, 2014 1:15 PM
Points: 2,834, Visits: 3,071

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. 

 

Post #348176
Posted Wednesday, February 28, 2007 10:05 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 20, 2007 2:28 PM
Points: 7, Visits: 1
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
Post #348193
Posted Wednesday, February 28, 2007 10:10 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Wednesday, October 8, 2014 4:15 AM
Points: 20,581, Visits: 9,619
Her name is loner.  Old hand is a nickname given based on the number of posts the person wrote.
Post #348195
Posted Wednesday, February 28, 2007 10:27 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 20, 2007 2:28 PM
Points: 7, Visits: 1
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.
Post #348208
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse