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

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon Apr 22 03:15:33 2002

see below, plz.

Dick

----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc_at_conman.org>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, April 22, 2002 12:42 AM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)


> 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.

This first conclusion is flawed, methinks. The second may be valid, but I
don't thing the third follows.

It's true that there are lots of books on how to use various software
applications. Having lots of them is good because people will want to use the
software in different ways and not always in the same way. Programmers should
read these books so they know how programs are used. They should also read
them to find out how useful a helpful error or diagnostic message can help.
As for the quality of documentation, I've found statements in Linux documents
that were so outdated as to be patently false, having omitted critical terms
such as "NOT."

> > 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?
>
No, I don't wonder. This situation can't be blamed on the mangers either,
though, because the programmers shouldn't tolerate this. I've jumped more
than one manager when, as chief engineer, or engineering lead, I overheard the
mgr, seemingly perched like a vulture on the programmer's shoulder said, "can
you do this?" to which the programmer says, "yes ... but..." and before he
finishes the mgr hits him with, "well, how long will it take?" and so on
until the programmer has consented to perform 256 hours' work in the next
week, without letting any of his previous assignments slip.

This was always of concern to me when I was responsible for schedule and
budget, not to mention morale. One ExVP ultimately fired me, in part because
I jumped him every time he did that because he was so accustomed to it. He
simply beat on the guy he wanted to do the work until he told him what he
wanted to hear. If programmers would say, "OK, I can do that if you don't
mind a slip of ... on this item and a slip of ... on that one, plus 80 hours
of overtime, which I'll want as comp so I can regain my sanity before getting
back into the harness. Another thing managers hate is a memo asking them to
spell out the task assignments they've made without consulting with senior
engineering.
>
> 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.
>
There'll always be disgreement on what's wanted, until it's written down and
signed. If you can, get your boss to write you a "statement of work" which
includes your precise requirements including test criteria and schedule.
Usually schedule and workload can be adjusted early in the project, so if it
doesn't suit you, or, if, early in the progress of the work, you discover a
serious obstacle, that can be dealt with rationally. If you just quietly go
away, letting him plan his schedule on your acceptance of his schedule and
task loading, it's on you. If he doesn't allow you any input, it's on him,
and you should emphasize those issues in a memo. It won't help either of you
to pretend the problem doesn't exist.
>
> 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?
>
No ... I already have a debug monitor, in fact a half-dozen of them, but I
want to build one with a line-by-line assembler, like what was in all the ones
on which I cut my teeth. The CP/M DDT or MSDOS DEBUG is an example. Every
one of the early Motorola MCU's was supported with at least one, but often
several useable debug monitors, each of which had a line-by-line
assembler/disassembler, so you could patch code in mnemonics rather than
having to hand-assemble your code (you learned to do that quickly enough
anyway). What I wanted was some source code examples in native code for the
805x core, so I could examine them to see whether any of them could benefit
from the features and facilities of the disassembler already on hand. Since
I'm planning to make some considerable enhancements to take advantage of the
features of a newer version of the device, I'm wanting to get the available
stuff together and study it out before I put it together.
>
> > 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 ... )
>
Perhaps the programmers should simply refuse to work that way, rather than
abjectly refusing to adhere to formal specifications, established policies,
etc. Either way, they're likely to be fired when all is said and done.

There's plenty of blame to go around, but if people would concentrate on doing
their jobs properly, things would improve. Too many guys focus on being a
standout rather than doing the work they were hired to do. If your manager is
really fiddling with your work assignment to such extent that you can't work
in a rigorous way, and if he's not willing to write down the reuirements he
expects you to meet, then it's time to write him a memo with a copy to his
boss.
Received on Mon Apr 22 2002 - 03:15:33 BST