> Oh, I've seen reports of managers who won't believe that a particular task 
> actually takes 20 minutes, and "can't you just change it to only take 3 
> seconds?"

An extremely valuable skill of any specialist is the ability to explain 
stuff to non-specialists in a way they understand.  Telling your manager 
that it's compute bound on 4 threads and is proven to not run any faster 
than the O(n^3) algorithm you are using is not going to work too well... 
(unless your manager is also a "specialist").

> After the consultants laughed and told them it was impossible, they made a 
> stroppy retort
*

> I guess the root of all this is people who have no concept of what is or 
> isn't possible with a computer. But it's more than that - people who have 
> no clue but *think* they do.

And it's people like that on both sides that cause the problem, which just 
leads to the problem getting worse.  On the one hand you have stroppy 
companies who have no clue about computers, but refuse to believe what they 
are told.  On the other hand you have supposed "specialists" who actually 
don't know what they are talking about.  Who's going to believe who anymore?

> I mean, if a bridge was being designed, you wouldn't presume to know 
> enough about structural engineering to make decisions about how long it 
> should take or what the best way to do it is.

Hahahahahha.  I take it you've never worked as an Engineer on a project 
then?  Almost every problem is due to the customer saying "I want X" and the 
Engineers saying "ermm we can't really do that".  Of course the customer 
usually forces the way they want, but then other things need changing or go 
wrong later.

A recent example is the LCD that goes in the instrument cluster of some car 
to be launched soon.  It goes behind a dark glass cover so that the driver 
cannot see anything behind, the display just kind of "glows" through it 
(like some Sony MP3 player i saw the other day).  Anyway, near the end of 
the design phase of the project, they told us they wanted it about twice as 
bright because they had made their dark glass darker than before.  We told 
them this was a bad idea as there might be problems with overheating etc. 
Of course they forced their way and told us they'd done tests etc and it was 
ok.  So guess what, we made it brighter, and now it shuts off during the 
high-temperature test because of overheating...  And as usual this is a 
"problem" with our design and we have to fix it at our expense asap....

Post a reply to this message

scott wrote:
>> Oh, I've seen reports of managers who won't believe that a particular 
>> task actually takes 20 minutes, and "can't you just change it to only 
>> take 3 seconds?"
> 
> An extremely valuable skill of any specialist is the ability to explain 
> stuff to non-specialists in a way they understand.

I like to think I'm fairly good at this. I'm probably just deluding 
myself though...

>> I guess the root of all this is people who have no concept of what is 
>> or isn't possible with a computer. But it's more than that - people 
>> who have no clue but *think* they do.
> 
> And it's people like that on both sides that cause the problem, which 
> just leads to the problem getting worse.  On the one hand you have 
> stroppy companies who have no clue about computers, but refuse to 
> believe what they are told.  On the other hand you have supposed 
> "specialists" who actually don't know what they are talking about.  
> Who's going to believe who anymore?

True...

I think if we could sort out who the *real* experts are from the liers 
and fakers, we'd probably be in better shape though.

>> I mean, if a bridge was being designed, you wouldn't presume to know 
>> enough about structural engineering to make decisions about how long 
>> it should take or what the best way to do it is.
> 
> Hahahahahha.  I take it you've never worked as an Engineer on a project 
> then?  Almost every problem is due to the customer saying "I want X" and 
> the Engineers saying "ermm we can't really do that".  Of course the 
> customer usually forces the way they want, but then other things need 
> changing or go wrong later.

OK, I rephrase: *I* wouldn't presume to know about structural 
engineering. ;-)

Post a reply to this message

> OK, I rephrase: *I* wouldn't presume to know about structural engineering. 
> ;-)

But, like with a lot of subjects, most people think they know the basics. 
Like if I told you that your new server room could only take 3 servers 
otherwise the floor would break, you would probably suggest that I made the 
floor stronger... If I then said this was not possible due to X, you (ok, 
not you personally) would either let it go or get angry and tell me to make 
the floor stronger as it *must* be possible.  You might then start to look 
at the details yourself and see if some beam could be made larger, you might 
even demand that I put in this bigger beam instead.

Then when the walls below collapse due to increased weight of the servers 
and the bigger beams you'll blame me :-)

Post a reply to this message

scott wrote:
>> OK, I rephrase: *I* wouldn't presume to know about structural 
>> engineering. ;-)
> 
> But, like with a lot of subjects, most people think they know the 
> basics. Like if I told you that your new server room could only take 3 
> servers otherwise the floor would break, you would probably suggest that 
> I made the floor stronger... If I then said this was not possible due to 
> X, you (ok, not you personally) would either let it go or get angry and 
> tell me to make the floor stronger as it *must* be possible.  You might 
> then start to look at the details yourself and see if some beam could be 
> made larger, you might even demand that I put in this bigger beam instead.
> 
> Then when the walls below collapse due to increased weight of the 
> servers and the bigger beams you'll blame me :-)

Mmm... clearly I'm not as much of a butthole as the people you get to 
work with. :-}

Post a reply to this message

> Mmm... clearly I'm not as much of a butthole as the people you get to work 
> with. :-}

Maybe you would be if you'd already ordered 10 new servers and announced to 
the entire company that the new system will be up and working by date X, and 
everyone is planning their own work based on your date, and if you don't get 
those servers running you will be responsible for your company losing a lot 
of money... And if you have no other options on where to put the servers, 
you're going to be on my back to make them go in that room whatever it 
takes...

And here's what happens when you mess with stuff:

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

Post a reply to this message

Gail Shaw wrote:
> Warning, rant follows. If you're not interested, don't read further.
> 
> So, yesterday my boss asked that I take a quick look at a couple of the
> scripts for a rather major change to our one system that's going live
> tomorrow evening. I wasn't overly concerned, because the code had already
> been checked over.
> 
> 
> *sigh*
> 
> I feel a bit better now.
> 

WOW - I feel for you.

Since you've been dragged in to 'check' it, are you now responsible to 
'care' for it.  Then I REALLY feel for you.

All I have to say is - "Good Luck!"



Tom

Post a reply to this message

"Tom Austin" <taustin> wrote in message news:47594dde$1@news.povray.org...

>
> Since you've been dragged in to 'check' it, are you now responsible to
> 'care' for it.  Then I REALLY feel for you.

I'd be responsible to care for it even if I hadn't seen it.

I'm the person the users call when the database apps are slow, so slow code
in production is automatically my responsibility.
Persionally I'm glad I found it this week and not next week.

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message
news:47591445@news.povray.org...
>
> Of course, The Real WTF is that they're asking you to check stuff over a
> few days before it goes live. ;-)

Actually I prefer that to the alternative: finding the mess in production
next week when someone complains.

My boss had no reason to suspect that anything was wrong. He asked me to
check a couple scripts just to make him happy. He's now very unhappy. *g*

> Me: "Every determinent is a candidate key."

My colleagues think it's strange that I can list, from memory, the
requirements for each normal form, some 10 years after university. They
think its even stranger that I can look at a table and tell in a couple
seconds what normal form its in.

Post a reply to this message

Gail Shaw wrote:
> "Invisible" <voi### [at] devnull> wrote in message
> news:47591445@news.povray.org...
>> Of course, The Real WTF is that they're asking you to check stuff over a
>> few days before it goes live. ;-)
> 
> Actually I prefer that to the alternative: finding the mess in production
> next week when someone complains.

True. But finding out 2 weeks ago would have been even better, no?

> My boss had no reason to suspect that anything was wrong. He asked me to
> check a couple scripts just to make him happy. He's now very unhappy. *g*

Ah, but can your boss actually do anything about this mess? That's the 
crucial question... ;-)

>> Me: "Every determinent is a candidate key."
> 
> My colleagues think it's strange that I can list, from memory, the
> requirements for each normal form, some 10 years after university. They
> think its even stranger that I can look at a table and tell in a couple
> seconds what normal form its in.

Yeah, cos after all, it's not like normal form is *important* or 
anything, is it?

*weeps softly in the corner*



By the way... what *is* 4th normal form?

(I was one of the few people in the class who could understand the 
normal forms - and why they matter - but we never looked at anything 
above BCNF.)

Post a reply to this message

Gail Shaw wrote:
> "Tom Austin" <taustin> wrote in message news:47594dde$1@news.povray.org...
> 
>> Since you've been dragged in to 'check' it, are you now responsible to
>> 'care' for it.  Then I REALLY feel for you.
> 
> I'd be responsible to care for it even if I hadn't seen it.
> 
> I'm the person the users call when the database apps are slow, so slow code
> in production is automatically my responsibility.
> Persionally I'm glad I found it this week and not next week.
> 
> 

The I hope that you have an understanding boss who is willing to work 
with you.



Tom

Post a reply to this message