CS> My experience so far is that many (maybe event most) consultants are not very 
CS> good programmers and/or are unreliable as far as their 
CS> commitments go.  Actually, that applies for many 
CS> programmers who aren't consultants, too.  Sometimes I am 
CS> amazed that any software ever works given some of the 
CS> garbage I've seen passed off as source code.

Well, we see what deadlines can do to things like OS/2, where not all
 the beta problems get nailed in the subsequent release. There are
things at work beyond the control of the programming staff that impact
the  quality of the code.

On NEXRAD, a weather radar, we had to use mesocyclone algorithms from
 NCAR in Colorado, with no discussion with them. They coded out to 
500-800 lines of FORTRAN, but the "rules" were 90% of code had to be
50  lines or less modules and no modules > 100 lines. The resulting
modules  certainly were easy to maintain, but a nightmare to understand
or modify when, inevitably, NCAR came up with a new algorithm. Any
programmer  complaints did not go back to NCAR nor result in lifting
the module size rules, since this was a bid competition. This was a
real-time mini multi-processor application; I would not recommend using
OS/2 for  real-time work in the microsecond range without h/w aid and
some thought about writing custom device drivers. The MSR Backup
FTDRIVER.SYS seems  to be an example of a hefty bunch of real-time
stuff.

Contractors have even less pull, and you quickly learn to say, "Yes,
massa". "Consultants" are supposed to be listened to, but often work
most assignments as contractors. Maybe you have been blessed with 
superiors or employers who as managers "ran interference" for you so 
you could get the code done RIGHT, but too often it's "get it out the
 door" or "that's nice, but today, the NEW goal is...". There's a
cartoon run in San Jose Mercury called "Dilbert" that says it all.

___
 X KWQ/2 1.2e X Kangaroos don't look good on flags - Donald Russell

--- Maximus/2 2.01wb