Comment On That is Off-Limits As Well

Ahh I love a good horror story for finishing the day :-)

Could have been good to have something that detects the computers are still online thought, something else like hardware trouble could have happened as well.

The story should have ended after:
"One look at the machine and the problem was obvious.", followed by a "Uh, it's unplugged.".

Rather, it ended with pompous arrogance that greatly dwarfed the incompetence of the client.

If I don't say it someone else will - Frankinstein is the creator, the monster wasn't given a name by Mary Shelley,. it was just called "monster" or "creature".

This sounds REALLY similar to a previous WTF.... Except it was a cd-tray or tape reel or something I think... lol...

lol...

I gotta wonder what the SOP for a systems malfunction is at that government facility... Apparently it needs to include checking whether the system in question is turned on. Classic ;-)

What is sad is that I've been called to a problem and yes, it was unplugged, twice.

 

Once it was the actual computer that was unplugged, once it was the monitor.

 

/I have Captchas

No matter how many times it happens, as soon as someone complains of a problem with some code I've written I immediately start running through it all in my head to think of where I might have screwed up. I'll spend at least an hour quickly searching through functions and whatnot to track down the exact line where the program is crashing....

In the end, it's almost always a case of user error. My date validation code wasn't perfect and allowed them to enter "9/31/2005". Or some of my favorite calls are from people who can't get to a webpage I made. After I plug their network cable back in, they seem to do just fine though.

In the end, it's almost always a case of user error. My date validation code wasn't perfect and allowed them to enter "9/31/2005".

not what I'd call user error...

No geek alive can improve a systems idiot proofing faster then the world can improve idiots.

 

GoatCheez:

This sounds REALLY similar to a previous WTF....

Maybe because it was.... "I hope you don't mind me re-running this classic from two years ago"

In the end, it's almost always a case of user error. My date validation code wasn't perfect and allowed them to enter "9/31/2005".

None of my clients would allow me to pass that off as a "User error".  But I agree with you otherwise,  you just picked a bad example.  Users are idiots.

Anonymous:

GoatCheez:

This sounds REALLY similar to a previous WTF....

Maybe because it was.... "I hope you don't mind me re-running this classic from two years ago"

roflmao.... I have an excuse this time lol... This morning something got in my eye and I had to take a contact out... lol... I always seem to miss something... lol...

Anonymous:

No geek alive can improve a systems idiot proofing faster then the world can improve idiots.

Unfortunatly the more you idiot proof a system the more you hamstring it, flexability and idiots do not get along :(.

goat,

Curse you and your responding to yourself before I can get my response off!

You know, he could have plugged it in until you made the power cord off limits as well.

Anonymous:

The story should have ended after:
"One look at the machine and the problem was obvious.", followed by a "Uh, it's unplugged.".

Rather, it ended with pompous arrogance that greatly dwarfed the incompetence of the client.

You're telling me that...

1. The customer threatening to withhold payment to a small business
2. Being forced to listen to salespeople bitch and moan about how they're going to lose the contract
3. Having to drive to the client site
4. Waiting at the gate for two hours
5. And, finally, discovering that the power cord was pulled out...

...is not grounds for being a little snippy?

You've got more patience than I would have in that situation.  Of course, I've spent many years working in the "classified" spaces and I can assure the American taxpayer that the reason most DoD IT projects are classified is to hide the incompetance of the senior management that manage them. 

Just after college, I worked at a DoD subcontractor. We had a rather complex piece of equipment that required an excruciatingly long sequence of steps for an acceptance test. The instructions ran something like this:

Enter "abc"

Press "RUN"

<expect to see ...>

Enter "def"

Press "RUN"

<expect to see ...>

...

Enter "ghi"

<expect to see ...>

Enter "jkl"

After watching a QA person (from the gov't) running through the test, I noticed that they were sitting idle for over an hour. I asked what the problem was. They told me that they entered "ghi" and were waiting for the output on the screen. I looked at the instructions and *yelled* "PRESS RUN". They informed me that the instructions didn't SAY to press run. All I could do was laugh.

Mohammed was installing software to analyze data feeds in a security agency back in 2002? I'm surprised they didn't shoot him at the door.

Manni:

My date validation code wasn't perfect and allowed them to enter "9/31/2005".

Just some random thoughts on this.



September 31, 2005 is also known as October 1, 2005.  Technically,
there is nothing wrong about that date, it simply is not in its most
simplified form.  Afterall, dates are just length values (pick
your precision) on some predefined offset, even when not dealing with a
computer.



To make an analogy, I could represent 6 as either 2 * 3 or 6 * 1, and
both forms would be correct, perhaps just excessively verbose. 
But in this case, it is purely a style issue.  For a fun exercise,
try the following Java code.

DateFormat formatter = new SimpleDateFormat("MM/dd/yyyy");


System.out.println(formatter.parse("09/31/2005"));

That makes me not the only one to think about dates this way.

Anonymous:

Anonymous:

No geek alive can improve a systems idiot proofing faster then the world can improve idiots.

Unfortunatly the more you idiot proof a system the more you hamstring it, flexability and idiots do not get along :(.

This is why so many good features are intentionally hidden.

Anonymous:

Manni:

My date validation code wasn't perfect and allowed them to enter "9/31/2005".

For a fun exercise,
try the following Java code.

DateFormat formatter = new SimpleDateFormat("MM/dd/yyyy");


System.out.println(formatter.parse("09/31/2005"));

That makes me not the only one to think about dates this way.

Now try the following Java code.  You get an exception.  I don't know why they made the default "lenient" mode, but they try very hard to make sense of all sorts of nonsense in that mode.
 

DateFormat formatter = new SimpleDateFormat("MM/dd/yyyy");
formatter.setLenient(false);
System.out.println(formatter.parse("09/31/2005"));

On the other side, you did have the late E.F. Codd somewhere near your camp, if not actually in it.  He felt that date arithmetic could not be handled properly without accepting dates like '09/31/2005' into the database and normalizing the date for presentation -- with the normalization phase determining whether the date was the reined in to the last day of the month or rolled into the next month.

Anonymous:

If I don't say it someone else will - Frankinstein is the creator, the monster wasn't given a name by Mary Shelley,. it was just called "monster" or "creature".

File under: "Books I Act Like I've Read, But Haven't". Also in the file is "PC Repair for Dummies".

captcha: photogenic. (ie Frankenstein's monster was quite photogenic.)

[Si]dragon, I've never before read such extreme bullshit.

September 31, 2005 is also known as October 1, 2005.

No, it's not.

Technically,
there is nothing wrong about that date, it simply is not in its most
simplified form.

It's wrong.

Afterall, dates are just length values (pick
your precision) on some predefined offset, even when not dealing with a
computer.

Length is a measurement of physical dimension. It is never a measurement of time.

But in this case, it is purely a style issue.

No it's not.

No, actually the days are the same, just the system is different. His "system" seems to use 31 days in the month of September instead of the arbitrary 30.

It's like saying 11 is equal to B. You just need to know that one system is decimal and the other is hex.

Of course I'm speaking philosophically. In the case of [Si]dragon and Manni, I wouldn't expect a computer to get it right. Clearly programmer error in that case.

Anonymous:

No, actually the days are the same, just the system is different. His "system" seems to use 31 days in the month of September instead of the arbitrary 30. It's like saying 11 is equal to B. You just need to know that one system is decimal and the other is hex.

No, actually that example is not relevant.  It's like saying 11 is equal to the string "dog poop" in my randomly on-the-fly generated counting system. 

HeroreV:

[Si]dragon, I've never before read such extreme bullshit.

September 31, 2005 is also known as October 1, 2005.

No, it's not.

Technically,
there is nothing wrong about that date, it simply is not in its most
simplified form.

It's wrong.

Afterall, dates are just length values (pick
your precision) on some predefined offset, even when not dealing with a
computer.

Length is a measurement of physical dimension. It is never a measurement of time.

But in this case, it is purely a style issue.

No it's not.

M:  I came here for a good argument.

A:   No you didn't; no, you came here for an argument.

M:  An argument isn't just contradiction.

A:   It can be.

M:  No it can't. An argument is a connected series of statements intended
to establish a proposition.

A:   No it isn't.

M:  Yes it is! It's not just contradiction.

A:   Look, if I argue with you, I must take up a contrary position.


M:  Yes, but that's not just saying 'No it isn't.'

A:   Yes it is!

M:   No it isn't!A:   Yes it is!

M:  Argument is an intellectual process. Contradiction is just the
automatic gainsaying of any statement the other person makes.

(short pause)

A:  No it isn't.

Digitalbath:

Anonymous:

No, actually the days are the same, just the system is different. His "system" seems to use 31 days in the month of September instead of the arbitrary 30. It's like saying 11 is equal to B. You just need to know that one system is decimal and the other is hex.

No, actually that example is not relevant.  It's like saying 11 is equal to the string "dog poop" in my randomly on-the-fly generated counting system. 

However, you do need to account for Sept 31st if your system stores dates between 45 and 15 BC.

http://suryakant.wordpress.com/2006/01/24/a-mail-to-ai-list-at-mit-in-1997/

This story reminds me of the following:

http://www.bash.org/?5273

CAPTCHA:  foxtrot

snoofle:

Enter "abc"

Press "RUN"

<expect to see ...>

Enter "def"

Press "RUN"

<expect to see ...>

...

Enter "ghi"

<expect to see ...>

Enter "jkl"

After watching a QA person (from the gov't) running through the test, I noticed that they were sitting idle for over an hour. I asked what the problem was. They told me that they entered "ghi" and were waiting for the output on the screen. I looked at the instructions and *yelled* "PRESS RUN". They informed me that the instructions didn't SAY to press run. All I could do was laugh.

If they were testing the instructions as well as that the program worked, I'd call this perfectly valid.  Joe or Jane operator whom has to run these instructions may not know anything about the underlying system, and if the instructions say "Press Run" in some places that it's needed but not in others, it will cause problems later on. 

My fellow sysadmin and I always test each other's documentation by following it literally (with the other one watching over the shoulder).  It's the only way we can be sure that in a disaster someone else coming in cold without our head full of business knowledge and system quirks would be able to do the task in question (which is vital for any BCP type of things).

Anonymous:

snoofle:

Enter "abc"

Press "RUN"

<expect to see ...>

Enter "def"

Press "RUN"

<expect to see ...>

...

Enter "ghi"

<expect to see ...>

Enter "jkl"

After watching a QA person (from the gov't) running through the test, I noticed that they were sitting idle for over an hour. I asked what the problem was. They told me that they entered "ghi" and were waiting for the output on the screen. I looked at the instructions and *yelled* "PRESS RUN". They informed me that the instructions didn't SAY to press run. All I could do was laugh.

If they were testing the instructions as well as that the program worked, I'd call this perfectly valid.  Joe or Jane operator whom has to run these instructions may not know anything about the underlying system, and if the instructions say "Press Run" in some places that it's needed but not in others, it will cause problems later on. 

My fellow sysadmin and I always test each other's documentation by following it literally (with the other one watching over the shoulder).  It's the only way we can be sure that in a disaster someone else coming in cold without our head full of business knowledge and system quirks would be able to do the task in question (which is vital for any BCP type of things).

Agreed...  but would your fellow sysadmin and you sit and stare at a screen for over an hour before thinkings that maybe, just maybe, something isn't quite right with the documentation?

No argument about its "classic" status!

Anonymous:

http://www.bash.org/?5273

Now that's funny.

HeroreV:

[Si]dragon, I've never before read such extreme bullshit.

September 31, 2005 is also known as October 1, 2005.

No, it's not.

Technically, there is nothing wrong about that date, it simply is not in its most simplified form.

It's wrong.

Afterall, dates are just length values (pick your precision) on some predefined offset, even when not dealing with a computer.

Length is a measurement of physical dimension. It is never a measurement of time.

Length refers to a measurement of an interval.  It is OK to say "How long was the movie?", and expect an answer in units of time.

But it is not OK to talk about "September 31".  The calendar is a "thing", and it has a precise definition, and that definition does not include nonsense such as "September 31".

HeroreV:

Afterall, dates are just length values (pick
your precision) on some predefined offset, even when not dealing with a
computer.

Length is a measurement of physical dimension. It is never a measurement of time.

But in this case, it is purely a style issue.

No it's not.

So if I were to ask you how long you'd like me to bake your pizza, you'd have a problem with that?

Months, hours, minutes, seconds, days, are all units of length.

However, a date is a coordinate: 01 January 2006 isn't specifying a length, it's specifying a point, just as (3,8) specifies a point on the Cartesian plane, or "3 miles north" can reference a place rather than a measurement.

If 31 Sept. 2006 is supposed to be a reference to a point, and we can be assured that it's not a typographical error, there is a logical assumption: it is the day 30 days after 1 Sept. 2006, which would be 01 Oct. 2006.

To blindly accept 31 Sept. 2006, however, is to assume that user input is valid, and when was that a good design practice? If the system asks for confirmation on odd dates such as this, or 341 Jan. 2006, and the user agrees that they meant it, then I could calculating that December date.

Of course, with 9/31/2005, is that 01 Oct. 2005, or is that 9 July 2007?

Fine, here's an argument. Go and find any wall calendar, datebook, calendaring software, checkbook register, ANYTHING with a calendar printed on it and show me September 31st.

While I do heartily agree that time can be rendered as an offset (and most languages have a function that facilitates this), that doesn't mean that a standard date used for scheduling an event should be treated as an offset rather than an invalid date.

Do you think it would be acceptable for someone to send you a birthday party invitation for November -347, 2007?

There's also the question of user expectation. Users don't usually expect the system to try and guess what they meant when they enter invalid information. If they were trying to schedule something for the last day of September and it ended up getting scheduled on October 1st instead, that is an error. It's better to let the user try and fix it instead of making guesses. If the user accidentally schedules the payroll for September 299 instead of 29 because their finger slipped, do you want to be the one waiting for that check?

smbell:

Anonymous:

http://www.bash.org/?5273

Now that's funny.

Yeah...reminds me of my apartment...

CAPTCHA: bedtime...

9/31/2005 is NOT a date.  Intermediate values are not acceptable as input unless you feel like asking for trouble; they are NEVER acceptable as output.

Anonymous:

Fine, here's an argument. Go and find any wall calendar, datebook, calendaring software, checkbook register, ANYTHING with a calendar printed on it and show me September 31st.

Even if I found a print calendar with Sept. 31 on it, you wouldn't believe me...

This is probably printed by a few people:

http://www.lawyersweeklyusa.com/archives/pdf/promo/CalendarUSA.pdf#search=%22%22september%2031%22%20calendar%22


Further, these online calendars (as they're titled) don't mind Sept. 31 as a day for important activities:

http://www.dic.co.jp/eng/ir/calender.html

http://www.winona.edu/academics/CALENDAR.htm

http://mendosearch.com/events.php   -- It's a Harvest Festival!!

http://www.kccla.org/html/Calendar.asp?EventID=368&sMonth=9&sYear=2006

http://www.kobe-u.ac.jp/en/campuslife/university/calendar.htm  -- Take away Sept. 31, and you take away a day of Summer Vacation!

http://www.yourcongress.com/viewarticle.asp?article_id=91

Anonymous:

You're telling me that...

1. The customer threatening to withhold payment to a small business
2. Being forced to listen to salespeople bitch and moan about how they're going to lose the contract
3. Having to drive to the client site
4. Waiting at the gate for two hours
5. And, finally, discovering that the power cord was pulled out...

...is not grounds for being a little snippy?

That most certainly is not grounds for being snippy.  If he had verified the machine was plugged in and running over the phone, he wouldn't have had to make the trip to the client site.

Sean:

Anonymous:

You're telling me that...

1. The customer threatening to withhold payment to a small business
2. Being forced to listen to salespeople bitch and moan about how they're going to lose the contract
3. Having to drive to the client site
4. Waiting at the gate for two hours
5. And, finally, discovering that the power cord was pulled out...

...is not grounds for being a little snippy?

That most certainly is not grounds for being snippy.  If he had verified the machine was plugged in and running over the phone, he wouldn't have had to make the trip to the client site.

I think this part makes it sound like he certainly tried to figure out what was going on.  "A couple of direct phone call to the client and I still couldn't get a clear picture of what happened over there."  Of course, since it was government, he may not have talked to anyone at the actual site or any similar position to actually look at the units.  Plus, with threats coming in, you probably don't have the luxury of waiting around forever to get the right person on the phone...if that person even existed and wasn't on vacation.

Digitalbath:

Anonymous:

No, actually the days are the same, just the system is different. His "system" seems to use 31 days in the month of September instead of the arbitrary 30. It's like saying 11 is equal to B. You just need to know that one system is decimal and the other is hex.

No, actually that example is not relevant.  It's like saying 11 is equal to the string "dog poop" in my randomly on-the-fly generated counting system. 

Wait a second...that's my counting system! You'll be hearing from my attorney. We're going to sue you for $dog poop,grass,bicycle,garbage can dollars!

sincerely,
Richard Nixon

If someone just edits this wiki to include times when dates act like this, it would be true!



http://en.wikipedia.org/wiki/Modular_arithmetic

From a logical point of view (nevermind the fact that computer systems don't accept it):

Explain what's so wrong about calling Sept 31 the same as Oct 1, if it's OK to call Wednesday 24:00 the same as Thursday 00:00 (which is officially acceptable, but not commonly done).

Maurits:

9/31/2005 is NOT a date.  Intermediate values are not acceptable as input unless you feel like asking for trouble; they are NEVER acceptable as output.

Incidentally, there used to be a discussion site that gave all the post dates as dates in September 93 (with a suitably large day number). Unfortunately, I can't find it; I think they might've returned to more normal numbering.

Anonymous:

Explain what's so wrong about calling Sept 31 the same as Oct 1, if it's OK to call Wednesday 24:00 the same as Thursday 00:00 (which is officially acceptable, but not commonly done).

Dates and times are labels, they are not time itself.  If you say "30 days after the 1st of September" you are using an offset; if you say "September 31st" you are using a label.  We have defined the labels "Wednesday 24:00" and "Thursday 00:00" as equivalent labels to reference the same time.

makomk:

Maurits:

9/31/2005 is NOT a date.  Intermediate values are not acceptable as input unless you feel like asking for trouble; they are NEVER acceptable as output.

Incidentally, there used to be a discussion site that gave all the post dates as dates in September 93 (with a suitably large day number). Unfortunately, I can't find it; I think they might've returned to more normal numbering.

Since September ended a few months back with AOL's decision to stop providing Usenet access, I suspect they have.

Anonymous:

From a logical point of view (nevermind the
fact that computer systems don't accept it):
Explain what's so wrong about calling Sept 31 the same as Oct 1, if
it's OK to call Wednesday 24:00 the same as Thursday 00:00 (which is
officially acceptable, but not commonly done).

Isn't it a lot like how 361 degrees is a valid measurement of angle,
even if a circle only has 360 degrees?  While it wouldn't make
much sense as an input value from the start of a series of
calculations, these values can arise during calculations, and must be
accepted in order for the rest of the calculations to finish. 
Same thing for -90 degrees being the same as 270 degrees.  Maybe
September 31st would arise as a result of some date math, but should be
normalized before displaying.

Sean:

Anonymous:

You're telling me that...

1. The customer threatening to withhold payment to a small business
2. Being forced to listen to salespeople bitch and moan about how they're going to lose the contract
3. Having to drive to the client site
4. Waiting at the gate for two hours
5. And, finally, discovering that the power cord was pulled out...

...is not grounds for being a little snippy?

That most certainly is not grounds for being snippy.  If he had verified the machine was plugged in and running over the phone, he wouldn't have had to make the trip to the client site.

How could the client check quickly on the computer if it's down in the dungeon?  Besides, it's a nice change for a day and is a great story to tell the grandchildren or the punters at the pub.

Anonymous:

The story should have ended after:
"One look at the machine and the problem was obvious.", followed by a "Uh, it's unplugged.".

Rather, it ended with pompous arrogance that greatly dwarfed the incompetence of the client.

No, no, we're talking about the US Government here. In fact, the story should have been converted to the passive voice and expanded to a 30 page document (admittedly, half of them could say "this page intentionally left blank"). Then you'd burn another 3 months on an emergency procurement, or 6 months if you know where the "black" money is.

But the real WTF is that the power cord was not hardened. It should have been encased in 6" of Kevlar,  not to mention protected by a claymore and an iris scanner.

At my previous work place there was a standard PC where the file shares, customer database and some web applications ran. Occasionally it happened so that the cleaner unplugged the computer, which meant that nobody could access the services until somebody came to the office the next morning/Monday and started up the computer.