"Geeks" and licensing

From: Richard Erlacher <edick_at_idcomm.com>
Date: Sun Dec 16 13:13:48 2001

You're right, and it's a sad fact, but, though they're perhaps secondary to
"building something," they're not secondary to building something right. If
everyone involved in a product development cycle were appropriately interested
in and dedicated to project success, the meetings would run more smoothly.
However, I'm reminded of a development project, a blatant example of what
happens instead of "doing the job right," that I ran into in the aerospace
industry.

We had a task to develop a small lightweight flight data recorder for use on the
1553 Bus on the space shuttle. The agreed-upon and signed-off spec called for a
WORM drive, on the 5-1/4" form factor that they normally used, with a power
budget of about 26 watts and a weight allocation of <4.5 pounds (I'm not certain
of this).

After inquiring about spec's from the vendors, whose rep's had stood up in
meetings when the spec's were being signed off, I ultimately learned that not
one of the manufacturers who had claimed to "have" a product that met the
requirement that the WORM drive worked on the 1553 bus (a redundant avionics
serial bus used in relatively advanced flight equipment) actually had even a
functional prototype, or even a realistic "objective" specification for such a
device. They had all essentially lied in the meetings, assuming that some
"arrangement" could be reached at a later date so their product would be chosen
over one of their competitors' offerings. I learned that Cherokee Electronics,
a wholly owned subsidiary of Lockheed Electronics was shipping WORM drives to
Lockheed for use in their fighter aircraft. In fact, I learned quite a few
things that suggested the entire flight electronics industry was in a
considerable disarray. Ultimately, I decided to build a bridge between SCSI
which would support the drives, to Mil-STD-1553, which was the required hardware
interface that the host software expected to use.

Unfortunately, another individual, more strategically placed, in a political
sense, had, on a previous, albeit not space-flight oriented, flight system
development project, successfullyused a 75-pound Honeywell flight data recorder,
that used 250 watts or so, and felt that was what should be used. As it turned
out, I ended up leaving the project, he got the larger recorder spliced in,
though not working, NASA disqualified Martin Marietta from this phase of the
project because they totally overshot power and weight requirements and wouldn't
give ground, not having a suitable alternative, and, the project was aborted. I
guess I was the only one who really cared that the firmly recorded and
contracted spec's were met.

I'd say that those meetings, do more than give the suits a reason to draw a
paycheck, though I'd certainly agree it looks that way. I don't know about the
"Powerpoint Bull***t", since it's intended to facilitate "meeting material"
generation, but it is worth noting that PowerPoint contains a "bulls**t
generator" just to fill the white space before an outline is fleshed-out. It's
noteworthy that one of the problems in the industry is that those spec's that
are developed in the meetings are often ignored, at least somewhat, by the folks
who write code or develop hardware. As a consequence, the success/failure and
low/high quality of the end product is on the folks who write the code rather
than on the managers who generate those spec's. If managers, who get the credit
for the successes, were required by the simple fact that their subordinates
follow their instructions instead of doing things irrelevant to the task, which
is to follow the spec's whether they work or not, the product development cycle
would ultimately be worked out to where it succeeds. Instead, the hipshooting
cowboys in the software department end up fighting over the credit for successes
and blaming the failures on those in absentia.

Dick

----- Original Message -----
From: "Dave McGuire" <mcguire_at_neurotica.com>
To: <classiccmp_at_classiccmp.org>
Sent: Saturday, December 15, 2001 10:25 PM
Subject: Re: "Geeks" and licensing


> On December 15, Richard Erlacher wrote:
> > Well, perhaps the reason for all the meetings and other work you find
> > uninteresting is that it's necessary to arrive at a firm specification for
what
> > you have to build before you go off and build it. Since the coding,
compiling,
> > and debugging only represent about 5% of the task, the bulk of the work has
to
> > happen sometime, and that's what the "other" stuff is.
>
> Some documentation and spefication has to happen, sure. But most
> of the industry seems to have lost sight of the fact that these are
> *overhead tasks* that are secondary to the job of *building
> something*. It gives suits a reason to take home a paycheck...they
> can shuffle paperwork and Powerpoint bullshit all they want; it
> rarely contributes to the finished product.
>
I don't agree that firmly establishing what has to be done is "secondary" to the
job of doing it.
>
> It's not an issue of my finding it "uninteresting"...I write code.
> That's what I do best. If I'm doing something other than writing
> code, I'm likely wasting my time...or worse, someone else's...because
> if I'm not writing code I'm probaby doing something I'm not
> particularly good at.
>
If you're a coder, your job is to follow the spec's you're given. You're not
paid to invent alternative ways to do things, but, rather, to implement, and
precisely so, the specifications you're given an NOTHING else.
>
> I'm not trying to be argumentative here...though it may sound that
> way, please don't take it as such.
>
I'm not that easily offended. Argument is a useful tool in establishing the
truth, BTW. It's just that you have to ensure your arguments aren't fallacious
or even completely irrelevant to the point.
>
> Again I will qualify my statements as pertaining to sub-million-line
> development projects, not huge multi-million line behemoths.
>
It's quite true that the problems in programming-in-the-large there are problems
not encountered in small programs. Requirements specification is required, even
if there's only one line of code, though.
> -Dave
>
> --
> Dave McGuire
> St. Petersburg, FL "Less talk. More synthohol." --Lt. Worf
>
>
Received on Sun Dec 16 2001 - 13:13:48 GMT