Micro$oft Biz'droid Lusers (was: OT email response format)

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Mon Apr 22 01:42:56 2002

It was thus said that the Great Richard Erlacher once stated:
>
> From: "Sean 'Captain Napalm' Conner" <spc_at_conman.org>
>
> > [1] For various values of documented. Using only the documentation that
> > comes with Microsoft Word (hardcopy or the help files) can someone
> > be reasonably expected to learn how to use Word?
>
> I'd say so. My 80+ year-old mother did.

  Well, kudos to her then.

> > Seems like books on *using* software is crowding out books about
> > *writing* software at the bookstores. And to me, that says that
> > the documentation that comes with software is so lacking that a
> > market of third party documentation is viable. So I might contend
> > that your assertion of ``better documented'' is invalid.
> >
> If programmers knew what computers were intended to do, perhaps they could
> figure out what to do with them. I'd say a goodly share of what passes as
> software today, including that from Microsoft, does nothing at all related to
> what the user thinks it should do, based on the writeups. Further, I'd guess
> that at least half of the programmers who have worked on a given piece of
> software, whether for UNIX or Windows, can't agree on what it is supposed to
> do. Additionally, I'd guess that, of the half that agree on what the program
> is intended to do, half can't tell you whether it does that, and of that half,
> another half can't tell you what their own code was intended to do or whether
> it does that.

  Setting: my office at a webhosting company I used to work for.
Boss/partner comes in.

  ``Sean, can we do blah?'' he asks.

  I think about it for a few moments. Doing blah would require this, that
and the other thing and it would take a while to get done, but ... ``Yes, I
think that's possible.''

  ``Good,'' he says. ``I just sold blah to a customer so we need it by
tomorrow.''

  Repeat that story any number of times at any number of software companies.

  Or how about:

  ``Oh, the customer wants the program to do yada yada instead of blah
blah.''

  ``But I thought we agreed that we implement blah blah and only blah
blah?''

  ``But the customer now wants yada yada.''

  ``Okay, but you just threw out foo months of work.''

  ``Oh, and we're still bound by the original deadline.''

  And you wonder why software is so crappy?

  We programmers can't agree on what to do because management, sales, or
even the customer can't agree on what they want. Microsoft is successful
partly because they have the resources to change on a dime, partly because
they control 90% of the consumer desktop market and can dictate what we
want, and partly because they have a marketing department from Hell.

  Tell you what, I'll spec a program for you to write that will take, say,
six months. Two months from now I'll add some unreasonable features and the
following month, change the specs completely on you, and still hold you
responsible for the original deadline. Oh, and in month five, I'll add even
more contradictory features, and two weeks before the deadline, add the
condition that you have to support the original spec as well.

  Does that sound okay?
  
> For weeks, I've been looking for a line-by-line assembler to run on an 805x
> CPU. I've asked in a number of lists, newsgroups, etc, and gotten numerous
> replies, all of which has convinced me that of the hundreds of millions of
> people out there who fancy themselves as programmers, fewer than 1ppm even
> know what a debug monitor is.

  Um ... you asked for a line-by-line assembler, but you really wanted a
debug monitor ... um ... so why didn't you ask for a debug monitor in the
first place?

> Back a few years, an assembler wasn't considered complete unless it could
> assemble itself, and, likewise, a compiler wasn't complete until it could
> compile itself. Today's tools won't do that in most cases. I think the
> problem is that people don't know how to specify and how to finish a piece of
> work. It's certainly true of most programmers that they simply don't adhere
> to specifications based solely on design requirements. Many CAN do that, but
> most won't. I'm not sure what, exactly, this means, but I suspect some
> profound truth relating to the general decay of the computer software we see
> these days owes its origins to it.

  I think programmers can adhere to specifications based solely on design
requirements *when they don't change!* I have a friend that will *only*
program to the specifications and he demands that they don't change *at all*
or he won't do the work. And yes, he's gotten into some heated discussions
with clients about that. But he can say that he has followed the spec to
the letter, on time and within budget.

  -spc (Oh, forgot to tell you ... I won't tell you the specs at all, but
        that shouldn't affect the time schedule any ... )
Received on Mon Apr 22 2002 - 01:42:56 BST