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.

Have you asked the boss why the system wasn't tested thoroughly prior to 
setting a date to go live?

If there ever was a #1 rule for any complex system, it's got to be "make 
sure the *#%$@! thing works before you depend on it."

And for contractors, the #2 rule should be "make sure their stuff works 
before you pay them."

And rule #3 is "An IT system is done when it is done; pressuring people 
to finish quicker will only increase the chance that they will deliver 
an unsatisfactory system."

Rules 1 and 3 were violated in the 2002-3 time frame in the US Air 
Force.  A new personnel database system was put into operation, and 
there were immediately problems with all sorts of personnel data 
operations.  The problems were so pervasive that there is simply no way 
there could have been adequate testing of the system.  Somebody gave the 
order to go live without first ensuring that the *#%$@! thing worked.

Regards,
John

Post a reply to this message

Programming is still such a black magic to the majority of people that
even today, as of 2007, anyone who claims to be able to program must be
a genius, and everything he says must be the Truth.

  I find it rather perplexing and worrying that even currently there are
many employers hiring programmers solely on the basis that the person
itself claims he knows how to program. Also anything the person says is
automatically taken as the truth. For example, if the "programmer" says
that something cannot be done, that must be the Truth, the whole Truth
and nothing but the Truth. Even the idea that it's simply a case of the
programmer not knowing how to do it doesn't cross the employer's mind.

  And of course these employers completely lack the notion that a program
can be inefficient and that more efficient solutions might be possible.
If a program takes 2 minutes to perform some task, that must be because
the task really requires 2 minutes to compute. It never crosses their
minds that maybe, just maybe, it's taking 2 minutes because the program
is crap. I believe that at least some of these people seem to think that
there's only one way to implement any given problem, and thus all possible
implementations are equally fast, ergo any given implementation is the
normal implementation and there can't be anything better. The only way to
make it faster is to buy a faster computer (a notion often reinforced by
the claims of incompetent programmers who can't admit that they just don't
know how to do it properly).

  Maybe this is because employers have the same attitude towards programmers
as they do towards other specialists, such as for example structural
engineers. If a structural engineer says that the proposed type of bridge
cannot be implemented, that's probably the truth. He is a professional,
probably has a lot of experience and he knows what he is talking about.

  While it's usually valid to believe anything a structural engineer claims,
employers fail to realize that programming is a completely different matter.
Not many people go around claiming they are professional structural
engineers when they really aren't. If they get caught they might be even
hold liable for caused damages. This is certainly not the case with
programmers: Anyone can claim he is a programmer, and it's quite difficult
to corroborate this, especially by someone who doesn't know anything
about programming.

-- 
                                                          - Warp

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote in message
news:47586156$1@news.povray.org...
>
> Seriously. Until I read this, I thought this kind of incompetent crap
> was only on thedailywtf.com and asktom.oracle.com. Now it seems it
> happens in The Real World too. This is... deeply worrying.

Of course. Where do you think those sites get their stories from? There are
idiots everywhere.

What really worries me is that, other than the contractor who I've never
met, I know these guys and they're neither stupid or careless. So how did
this happen? Oversight? Managerial over rule? Critical mass?

> (Hey, did you hear about the guy who hired a bunch of programmers to add
> multi-value columns to M$ Access? Because it's "impossible" to work with
> a product so primitive that it doesn't have this "important feature"?)

Um, first rule of normalisation - remove all repeating groups and
multi-valued attributes.

Wasn't that on daily WTF?

Post a reply to this message

"andrel" <a_l### [at] hotmailcom> wrote in message
news:475### [at] hotmailcom...
> > >
> Weren't you working for a bank?

Yup. An investment bank

> With the holidays coming, why don't you
> just shut down till januari, nobody will notice anyway.
>

I wish. Year end is end of this month so things are getting busier, not
quieter

Post a reply to this message

"John VanSickle" <evi### [at] hotmailcom> wrote in message
news:47588b48@news.povray.org...

> Have you asked the boss why the system wasn't tested thoroughly prior to
> setting a date to go live?

My boss (head of the production support area) wants to know that too.

One of the problems we have is a lack of technical management in the
development area. Probably a business head set the date and no one had the
guts or authority to overrule. Or more likely the business head set a date,
the project manager said fine and no one ever consulted the developers.
That's happening far too often

The other issue to consider is that the year-end system freeze starts on
monday and no further changes are permitted to the production systems til 16
Jan.

> If there ever was a #1 rule for any complex system, it's got to be "make
> sure the *#%$@! thing works before you depend on it."

Why? Fixing stuff in production is so much fun and give the lazy support
staff something to do. Especially over christmas where otherwise they'd be
lazing around with their families. </sarcasm>

> And for contractors, the #2 rule should be "make sure their stuff works
> before you pay them."

It does work. For very loose definitions of work. In the development
environment

> And rule #3 is "An IT system is done when it is done; pressuring people
> to finish quicker will only increase the chance that they will deliver
> an unsatisfactory system."

I fully agree with you. I'm sick of the project managers setting
completion/go-live dates before the design is even started

The whole reason for this is because we were bought out last year and we
have to 'align our business processes with the parent company'

Post a reply to this message

> Probably a business head set the date and no one had the
> guts or authority to overrule. Or more likely the business head set a 
> date,
> the project manager said fine and no one ever consulted the developers.
> That's happening far too often

Yep, that happens here too.  The "project manager" often doesn't know enough 
about the details of the project, and will agree things with their boss and 
our customers without even consulting the people underneath.  Then we get 
all sorts of problems later, both due to lack of time and struggling to meet 
the agreed performance.  Does get people to work hard though mind you ;-)

Post a reply to this message

>  Maybe this is because employers have the same attitude towards 
> programmers
> as they do towards other specialists, such as for example structural
> engineers. If a structural engineer says that the proposed type of bridge
> cannot be implemented, that's probably the truth. He is a professional,
> probably has a lot of experience and he knows what he is talking about.

Plus you'd get one who was chartered (or a member of the equivalent 
professional institution in your country), so you can be sure he has a 
certain level of experience and expertise in his field.

Does anything equivalent exist for programmers?

Post a reply to this message

>> Seriously. Until I read this, I thought this kind of incompetent crap
>> was only on thedailywtf.com and asktom.oracle.com. Now it seems it
>> happens in The Real World too. This is... deeply worrying.
> 
> Of course. Where do you think those sites get their stories from? There are
> idiots everywhere.

I thought (hoped?) that only stupid companies employ people who can't do 
their job properly. Apparently I was wrong...

> What really worries me is that, other than the contractor who I've never
> met, I know these guys and they're neither stupid or careless. So how did
> this happen? Oversight? Managerial over rule? Critical mass?

Time pressure? Insufficient QC? Who knows...

Of course, The Real WTF is that they're asking you to check stuff over a 
few days before it goes live. ;-)

>> (Hey, did you hear about the guy who hired a bunch of programmers to add
>> multi-value columns to M$ Access? Because it's "impossible" to work with
>> a product so primitive that it doesn't have this "important feature"?)
> 
> Um, first rule of normalisation.

"Wot's normalizashun?"

> Wasn't that on daily WTF?

Yes, that's where I read it. Gave me a good giggle...



An extract from one of my Database Design lectures at Uni:

We are all gathered in room EWS14. There's approximately 40 of us. Ian 
Eyeball is at the front, lecturing us about normalisation and the 
potential problems that disregarding it can have.

Ian: "So, we have 1st normal form - which you never ever want to break. 
Then there's 2nd normal form and also 3rd normal form, then we come to 
Boyce-Codd normal form. There are higher normal forms, but you don't 
need to care about those. For the most part, you just need to make sure 
your tables are in Boyce-Codd normal form, which says - *Andrew*"

[I stand up]

Me: "Every determinent is a candidate key."

[I sit down again]

Ian: "Thank you Andrew."

[General amusement]

[Ian continues with the lecture.]

Post a reply to this message

> Plus you'd get one who was chartered.
> 
> Does anything equivalent exist for programmers?

I don't think so - but there probably should be...

Post a reply to this message

Warp wrote:

>   And of course these employers completely lack the notion that a program
> can be inefficient and that more efficient solutions might be possible.
> If a program takes 2 minutes to perform some task, that must be because
> the task really requires 2 minutes to compute. It never crosses their
> minds that maybe, just maybe, it's taking 2 minutes because the program
> is crap.

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?"

I'll never be able to find the link now, but there was one company who 
phoned up some web design consultants and said they wanted them to build 
a website that shows DVD-quality fullscreen video but loads in under 1 
second on a 56k modem.

"Gee, what an awesome idea! I'm sure you're going to corner the market 
with that one. Good thing nobody else has thought of this revolutionary 
idea... Oh wait, they have, and they found out it's impossible. Oh well, 
I'm sure being impossible is no obsticle for visionaries like yourself."

After the consultants laughed and told them it was impossible, they made 
a stroppy retort and threatened to "take their business elsewhere". The 
consultants said they were perfectly happy for that to happen. 
(Unsurprisingly, really.)

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. 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. And yet people who know nothing about computers 
seem to think they can do this with software engineering...

Post a reply to this message