!Re: Nuke Redmond!

From: Sean 'Captain Napalm' Conner <spc_at_armigeron.com>
Date: Sat Apr 8 23:23:15 2000

It was thus said that the Great Richard Erlacher once stated:
>
> > I even talked to the original programmer and his attitude was basically
> > ``Hey, the customer paid for it and it works. I'm not working on it again.
> > Screw you dude!'' It's rare when I want someone else shot on sight, but he
> > was one of them.
>
> The notion that the original programmer will live forever, hence, always be
> available to fix things, is one of the main weaknesses of programming
> philosophy. Even I have fallen into that one. That's why plgramming
> languages have a construct for comments.

  It's not that the programmer will live forever, but that a programmer
doesn't have to live with his mess that upsets me more. Once the code
becomes a quagmire he can leave it behind and move on, much like the fellow
whose code I had to maintain (or the sysadmin whose network I inherited. I
swear I wanted to drag him back (behind my car) to the office and force him
to fix his poor excuse for a network but I digress ... )

  Then there was a job I held for two weeks at a software company. Their
coding standards mandated NO COMMENTS! Their rational---comments are often
misleading and don't match the code. So the code IS the COMMENT, as that's
what the computer is executing (and I won't go into their other insipid
coding standards). I left over major disagreements over coding standards.

  [ some slight shuffling of paragraphs here ]

> Well, heuristic progamming is the hallmark of the American school of
> programming. The Japanese have, in recent years actually applied genuine
> and therefore 30+ (probably much older) year-old engineering principles to
> software engineering, a term which, in the American school, is still an
> oxymoron, and have regularly been reported to be bringing software tasks in
> within both budget and schedule.

> > [2] In C with random indentation, C++ style comments (which his C
> > compiler accepted) and race conditions that would cause it to
> > fail under certain circumstances.
>
> Well, that's not as bad as finding potential catastrophic failures and
> dispensing with then by changing the ground rules. That's how NASA likes to
> do it.

  I'm not entirely sure what's happened with NASA recently, but during the
90s I read that the software development group for the Shuttle had the
highest quality assurance program period, and that up to January 1986, there
had been only two bugs that made their way to the shuttle simulator (which
is considered earth shattering bad among the programmers). Since 1986 I'm
not sure if it has declined, but I did read an article within the last year
that upheld the fine tradition of NASA programmers with being on time and
within budget, all while working 40 hour weeks (which is something not even
heard of in the industry).

  It might be NASA management doing the fiddling, but I doubt it's the NASA
programmers. I wish more was written on the NASA programming teams.

  -spc (Or marketing hit with large clue sticks)
Received on Sat Apr 08 2000 - 23:23:15 BST