!Re: Nuke Redmond!

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sat Apr 8 11:13:18 2000

please see embedded comments below.

Dick
----- Original Message -----
From: Sean 'Captain Napalm' Conner <spc_at_armigeron.com>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, April 08, 2000 2:45 AM
Subject: Re: !Re: Nuke Redmond!


> It was thus said that the Great Richard Erlacher once stated:
> >
> > If you were thumping Billy Gates and his friends by hinting that they
simply
> > bought something and filed off the rough edges and nibbled at the edges
> > where it didn't fit, well, that's legitimate business. You might not
see
> > that as innovation (just to bring this discussion back to where we left
the
> > original thread) then keep in mind that those of us who use the software
> > every day care a lot more about whether it works than whether it is
totally
> > new. It would be truly innovative to have software weenies get used to
> > writing the code just as it was specified and leaving out every extra
"hook"
> > or whatever that wasn't in the spec, hence won't be accounted for in the
> > doc's.
>
> Just for the record, and speaking as a programmer, I would find it
truely
> innovative if software was actually DESIGNED for a change, instead of
hacked
> on. I count myself lucky that I don't have to work with other programmers
> or their code since I hear way too many horror stories from my buddies
that
> actually have to (and it's almost always worse when it involves anything
> dealing with Mircosoft [1]). The last time I had to work with someone
> else's code it was so horribly written [2] and obviously not designed that
I
> scrapped it and rewrote it.
>
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.
>
> 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.
>
> Spec? Spec? That's a good one.
>
Yes . . . I'm an engineer, and I have learned over the years that I
shouldn't take on work for which I don't have a qualifying
(test-on-delivery) specification. That's sort of an "if it does this I get
paid" test. This may encourage designing for the test, but that gets me off
the hot-seat as far as defining what "works" means. If this spec isn't a
part of the RFQ, then I make it part of the proposal process. Getting
unconditional or defined-conditional qualifying specifications is like
pulling teeth. Often it's my teeth . . . that's why I have several sets.
>
> > It would be truly innovative to have it tested systematically with a
wide
> > range of inputs, both random and systematic and to great depth to make
sure
> > that there's no way to make it go down the toilet, especially not by
> > inadvertent input at the "wrong" time or place. I'd say that at a
minimum
> > it ought to be tested with every possible input of a single character at
> > times when input is not expected and every combination of 2^32 chacters
at
> > every point at which input is anticipated. The software should behave
in an
> > entirely predictable way and give messages that are totally self
> > explanatory. Do I really think American programmers will ever take
their
> > work that seriously, . . . No, but they should at least think about
it,
> > don't you think? It could be done automatically, though, couldn't it?
> > First we should hope that the pro's learn not to write memory leaks, eh?
>
> First off, European programmers are no better. At least when we write
> unmaintainable piles of crap, it's because we don't know any better.
> Europeans they seem to just love writing complex code just for
complexity's
> sake. A friend of mine (B.S in Comp Sci from an American university) had
to
> explain to three German programmers (each with a Ph.D. from a European
> university) why their code was not re-entrant, and show an easier way to
do
> what they wanted to do in the first place. They refused to make the
change
> (which only impacted five places in the code) since their code was
> ``tested'' and obviously worked. Uh, no. It wasn't re-entrant. In that
> particular case, that was a bug waiting to happen.
>
I didn't mean to suggest that being elsewhere-born and trained would make a
programmer better. The art was defined by the sheer volume of code
generated in the early years of microcomputing when micromputers were more
available and more used in the U.S. than anywhere else. Consequently the
techniques spread. I doubt programming will ever be freed from the mantle
of "mystical art" or "right-brain activity" long enough to allow the
introduction of discipline. I'm beginning to believe that programming is
more a disease than an engineering discipline. It seems more folks get into
it indirectly and almost against their own wishes. Thank goodness that they
stick with it long enough to generate the tools we all use and love to hate.
>
> > > Although I might be more inclinded to remove redundant calls (that
differ
> > > only in device) but that's a step down the Unix direction.
> > >
> > That's a feature that came about when one fellow wrote one version and
then,
> > having become the boss, expected someone else to pick up where he left
off,
> > but not damage any of his now-sacred work.
>
> Well, it might also be a conscience design decision now that I think
about
> it. On a register starved 8080 it might not have been possible to specify
a
> device number, or might have increased the code size to load an extra
> register. It's hard to say.
>
> But what you say is the current Microsoft way from stories I've heard.
>
> > > Not outright. And it's not like MS-DOS used that as the ONLY way to
call
> > > the operating system---the preferred method was still INT 21h. I
suspect it
> > > was only put in to help migrate software from CP/M to MS-DOS.
> >
> > Now there's an interesting notion! A programmer actually did something
to
> > help out the struggling programmers who were going to have to live with
his
> > work. How thoughtful! You don't suppose those not-so-glaring
similarities
> > between the two OS' might actually exist because the authors thought it
wise
> > to make the environment familiar, or at least familiar-looking.
>
> That's entirely possible.
>
> This whole conversation started because you stated you didn't see the
> similarities between CP/M and MS-DOS. I came along and said that the
> similarities were lower down, below the user stuff. I never said that was
> good or bad. Other people seem to think Microsoft (or Tim Patterson) was
> wrong doing what they did. I haven't.
>
> > > -spc (Amature computer historian ... )
> > >
> > that's AMATEUR, you HISTORIAN
>
> Thank you.
>
> > WIth few exceptions, this tracks the PBS "revenge of the nerds" account
of
> > these events pretty closely. The thinly veiled truth must be in there
> > somewhere.
>
> Well, I never saw the PBS ``Revenge of the Nerds'' but I have read
several
> books (and countless magazine articles and reference materials) but I'm
> interested to hear what you think the truth is.
>
> -spc (AmaTEUR computer history then ... )
>
> [1] For instance, a friend of mine is writing a program to automatically
> restart programs if they stop running. Under Unix, this is already
> provided by the init program yet it's something that is lacking
> under Windows NT (which can run as a server, mind you). So he's
> basically writing a clone of init for NT. The problem is that he
> not only has to restart programs, but NT services, and that requires
> an entirely different set of API calls than starting and stopping
> programs (not to mention that you can get a signal when a program
> dies, yet you have to poll to see if a service is dead).
>
> The project he's on is a complete disaster as the manager went for a
> Microsoft solution using slews of programs communicating via COM,
> DCOM, OLE and other alphabet soup of Microsoft technology. A year
> later and it still doesn't work and my friend has basically told the
> manager it has to be scrapped and done from scratch, preferably
> using something other than Microsoft (although my friend might have
> a slight bias).
>
> [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.

BTW, your apparent juxtaposition of one word for its homomymn, and it
happens all too often with this particular one. There's this term,
pronounced "sloo" which is often misspelled "slew" but which should be
"slough" also pronounced "sloo" meaning a swamp or quagmire.

I've noticed this here in this forum several times in the last few weeks and
had to complain.
Received on Sat Apr 08 2000 - 11:13:18 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:40 BST