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