CS> My experience so far is that many (maybe event
CS> 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.

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

Deadlines are obviously problems at times and require that tradeoffs
between doing it right and doing it sloppily to get it done quickly be
made.  Even when deadlines haven't been an apparent problem, however,I've
seen a lot of code written by people who have years of
"experience" (whatever that means) that makes me wonder how on
earth I am ever going to figure out who to hire as additional programmers
if the time comes to do so.  Do you have any experience hiring programmers?
 If so, I'd appreciate any advice you may have.

 BC> On NEXRAD, a weather radar, we had to use mesocyclone algorithms from
 BC>  NCAR in Colorado, with no discussion with them. They coded out to
 BC> 500-800 lines of FORTRAN, but the "rules" were 90% of
code had to be

Ugh, FORTRAN is one of my least favorite languages, right up there with
assembler code.  Actually I might prefer assembler, depending on the
machine architecture.  Maybe FORTRAN has gotten to be a better language
with FORTRAN-90 (or whatever the newest standard is) that was supposed to
add dynamic memory allocation and many other useful features, but I've had
to read FORTRAN code in the past that was written by scientists and made me
contemplate faking illness. Fortunately it wasn't my job, I was just
helping out the poor person who had to figure out what the code was doing.

 BC> 50  lines or less modules and no modules > 100 lines. The resulting
 BC> modules  certainly were easy to maintain, but a nightmare to understand
 BC> or modify when, inevitably, NCAR came up with a new algorithm. Any
 BC> programmer  complaints did not go back to NCAR nor result in lifting
 BC> the module size rules, since this was a bid competition. This was a
 BC> real-time mini multi-processor application; I would not recommend using
 BC> OS/2 for  real-time work in the microsecond range without h/w aid and
 BC> some thought about writing custom device drivers. The MSR Backup
 BC> FTDRIVER.SYS seems  to be an example of a hefty bunch of real-time
 BC> stuff.

Yes, I'd agree that OS/2 probably is not suitable for applications that
require microsecond response times unless you are planning to add
additional specialized hardware.

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

The project I've been working on for the last couple of years has been
unfortunate enough to have had severe personnel turnover
problems,understaffing, and lots of requirements changes (some of them
major). However, in some ways this has been good for me personally as I'm
the only one who has been around for nearly the entire project and at this
point the investors and management seem to think I'm worth trusting because
I haven't ripped them off and haven't quit on them like the other
consultants have.


--- Maximus/2 2.01wb