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.

Well...

The tables aren't properly normalised. I asked the lead architect about this
and his reply was 'We didn't think it was really necessary.' I have three
tables that are not even in first normal form. Most of the others aren't in
second. The only ones in third are the lookup tables that only have 3
columns. It's not a problem, the architect says. Except this afternoon we
picked up data integrity issues (one country with multiple ratings where it
should have one), and the system isn't even running live yet.

The code is, to put it mildly, an absolute abomination. If the developer had
specifically set out to violate as many principles of good sql code, and to
break as many of our coding practices as possible it wouldn't be much worse.
Select *, everywhere, even on the tables with 100 columns
multiple uses of distinct, even when retrieving result sets that include the
pk column
multiple procedures that do the same thing, just with different hard coded
values. Parameters anyone?
useless error handling (return @@error right at the end of a multistatement
proc)
no transaction usage in multiple updates/inserts/deletes
row-by-row inserts from an etl process.

The whole thing is a performance nightmare waiting to happen. I ran across
one index this afternoon that made me want to hit my head against a desk
repeatedly. A composite clustered index on a 500 character string field and
a 36 character string, neither or which are ever searched on. (the column
that is searched on didn't have an index at all)

There's a view that the developer said 'returns instantly' It takes minimum
37 seconds, on the dev server. That's without production load and with a
cut-down data set.

The person who wrote most of this is a contractor who no longer works for us
The second person is a front end developer who knows almost nothing about
SQL. I'm wondering at this point why I bother at all. I've spent the entire
day today and most of this evening checking code. The only way to fix this
is a complete redesign, from the ground up. But it has to be working in
production by monday morning, so that's kinda out of the question.

I'd offer to give SQL workshops to the developers, but I think I'd be the
only person who attends. After all, databases are easy and anyone can write
SQL. Right?

*sigh*

I feel a bit better now.

Post a reply to this message

Gail Shaw wrote:

> I'd offer to give SQL workshops to the developers, but I think I'd be the
> only person who attends. After all, databases are easy and anyone can write
> SQL. Right?

Sure it is. After all, a database is really just a flat file with a 
built-in search function, right?

Right??

> *sigh*
> 
> I feel a bit better now.

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.

What you have described indicates that the people who did this have a 
thorough lack of understanding of WTF a database actually *is*!

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

-- 
http://blog.orphi.me.uk/

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.
> 
> Well...
> 
> The tables aren't properly normalised. I asked the lead architect about this
> and his reply was 'We didn't think it was really necessary.' I have three
> tables that are not even in first normal form. Most of the others aren't in
> second. The only ones in third are the lookup tables that only have 3
> columns. It's not a problem, the architect says. Except this afternoon we
> picked up data integrity issues (one country with multiple ratings where it
> should have one), and the system isn't even running live yet.
> 
> The code is, to put it mildly, an absolute abomination. If the developer had
> specifically set out to violate as many principles of good sql code, and to
> break as many of our coding practices as possible it wouldn't be much worse.
> Select *, everywhere, even on the tables with 100 columns
> multiple uses of distinct, even when retrieving result sets that include the
> pk column
> multiple procedures that do the same thing, just with different hard coded
> values. Parameters anyone?
> useless error handling (return @@error right at the end of a multistatement
> proc)
> no transaction usage in multiple updates/inserts/deletes
> row-by-row inserts from an etl process.
> 
> The whole thing is a performance nightmare waiting to happen. I ran across
> one index this afternoon that made me want to hit my head against a desk
> repeatedly. A composite clustered index on a 500 character string field and
> a 36 character string, neither or which are ever searched on. (the column
> that is searched on didn't have an index at all)
> 
> There's a view that the developer said 'returns instantly' It takes minimum
> 37 seconds, on the dev server. That's without production load and with a
> cut-down data set.
> 
> The person who wrote most of this is a contractor who no longer works for us
> The second person is a front end developer who knows almost nothing about
> SQL. I'm wondering at this point why I bother at all. I've spent the entire
> day today and most of this evening checking code. The only way to fix this
> is a complete redesign, from the ground up. But it has to be working in
> production by monday morning, so that's kinda out of the question.
> 
> I'd offer to give SQL workshops to the developers, but I think I'd be the
> only person who attends. After all, databases are easy and anyone can write
> SQL. Right?
> 
> *sigh*
> 
> I feel a bit better now.
> 
Weren't you working for a bank? With the holidays coming, why don't you 
just shut down till januari, nobody will notice anyway.










Just kidding.

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.

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

> 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

Invisible <voi### [at] devnull> 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?"

  True. Completely unrealistic expectations is another phenomenon among
programming-illiterate bosses...

  OTOH, I partially understand them: If they know nothing about programming,
how can they know how much time a certain task requires? And depending on
the trustability of the programmer, how can they know if what he says is the
truth or not?

> 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.

  "Hey, I took a 4-hour programming course in 1984. I know everything
about programming!"

-- 
                                                          - Warp

Post a reply to this message

"Tom Austin" <taustin> wrote in message news:47596e0a@news.povray.org...

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

My boss is understanding, the users on the other hand...

I enjoy the job. I just wish the developers didn't keep on creating work for
me. I have quite enough as it is.

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message
news:47596a5f$1@news.povray.org...

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

The ideal would have been finding out at design time. But is wishes were
horses...

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

He can't stop it going in, it's too late and too many people have been
promised, etc, etc. IT's getting a bad rep for late delivery as is.

He is middle-upper management and he has enough authority to demand a
redesign (which he has) and to decide who does that (which he has) and to
'suggest' an examination of the way the developers work, to ensure this
doesn't happen again.

I foresee a lot of meeting next week.

> Yeah, cos after all, it's not like normal form is *important* or
> anything, is it?
>
> *weeps softly in the corner*

To C# developers it probably isn't, just as the patterns for app design
aren't that important to me. But in that case, they should keep their
fingers out of the DBs

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

It's one I've seldom come across and doesn't apply often. Has to do with
multiple unrelated dependent attributes in a table.

Say we're writing a teaching management system. We need to store what
languages a teacher speaks and what courses they teach. We come up with
something like this

Teacher  Language  Course
Mr X      English      Account 1
Mr X      French      Account 1
Mr X      English      Ethics 1
Mr X      French      Ethics 1
Mrs S     English      Maths 1
Mrs S     English      Maths 2
Miss Z    English      History 1
Miss Z    German    History 1

It is in B-C normal form, however if we needed to indicate that Miss Z
starts teaching Archaeology 1, we need to add 2 rows.
4th normal form indicates that the two attributes should be split out into
selerate tables, so that there's one table that has the teacher's languages
and one that has the courses they teach.

That said, if the table stored the courses that the teacher offers and the
language that they are offered in, the above table would not be in violation
of 4th normal form.

Wiki has (as usual) a section on it
http://en.wikipedia.org/wiki/Fourth_normal_form

Post a reply to this message

scott wrote:
> 
> And here's what happens when you mess with stuff:
> 
> http://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse
> 

I used to live roughly in the KC area, and a friend of mine used to go 
to the "tea dances" at that place--thank goodness she wasn't there that day.

It definitely filled up the news for a while.

--Sherry Shaw

-- 
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}//                                   TenMoons

Post a reply to this message

Invisible wrote:
> 
> 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.

Never underestimate the power of managerial cluelessness.  As far as I 
can tell, most bosses think of programmers as something like peasant 
beet farmers.  We know how to do something they don't--not because we're 
  trained professionals or anything, but because bosses don't dirty 
their hands with that sort of thing.

Well, going to go scrub some code out from under my fingernails now.

--Sherry Shaw


-- 
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}//                                   TenMoons

Post a reply to this message

Sherry Shaw wrote:

> Never underestimate the power of managerial cluelessness.  As far as I 
> can tell, most bosses think of programmers as something like peasant 
> beet farmers.  We know how to do something they don't--not because we're 
>  trained professionals or anything, but because bosses don't dirty their 
> hands with that sort of thing.
> 
> Well, going to go scrub some code out from under my fingernails now.

Well, it could be worse. Ever read the daily WTF articles about the MDs 
who think they can program but actually can't? ("Stand back you clueless 
fools and let me show you how a *real* programmer does it!" "Yes boss.")

-- 
http://blog.orphi.me.uk/

Post a reply to this message

And lo on Fri, 07 Dec 2007 09:48:12 -0000, Invisible <voi### [at] devnull> did
  

spake, saying:

> 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 bui
ld  

> a website that shows DVD-quality fullscreen video but loads in under 1
  

> second on a 56k modem.

http://www.clientcopia.com/
http://clientcopia.com/quotes.php?id=15 perhaps.

-- 

Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Phil Cook wrote:
> And lo on Fri, 07 Dec 2007 09:48:12 -0000, Invisible <voi### [at] devnull> did 
> spake, saying:
> 
>> 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.
> 
> http://clientcopia.com/quotes.php?id=15 perhaps.

Yeah. That one.

-- 
http://blog.orphi.me.uk/

Post a reply to this message

Update:

2/3 of the change was pulled out on friday night, due to bugs. Some more was
pulled out on sunday when it didn't work right.

And business people were demanding (and getting) changes made to the spec
(and to the code) right up to and after the time it was deployed.

*sigh* I dunno why I bother....

Post a reply to this message

Gail Shaw wrote:

> Update:
> 
> 2/3 of the change was pulled out on friday night, due to bugs. Some more
> was pulled out on sunday when it didn't work right.
> 
> And business people were demanding (and getting) changes made to the spec
> (and to the code) right up to and after the time it was deployed.
> 
> *sigh* I dunno why I bother....

Teehee - we don't work at nearly the same scale that you apparently do, but
this is about par for the course.

Boss: "I PROMISE this is the spec, the only spec and nothing but the
spec..."

Client: "Hey! I saw this somewhere else, and it would be so cool if..."

You know the rest.
-- 
Stefan

Post a reply to this message