22 Apr
2002
22 Apr
'02
1:42 a.m.
It was thus said that the Great Richard Erlacher once stated:
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?
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
Well, kudos to her then.
[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. 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. 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 ... )