NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/std/unix/481

Internet Message Format | 1992-12-24 | 5.7 KB

Path: sparky!uunet!not-for-mail
From: [e-mail] (Andrew Hume)
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Date: 23 Dec 1992 22:12:13 -0800
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 90
Sender: [e-mail]
Approved: [e-mail] (Moderator, Sean Eric Fagan)
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: ftp.uu.net
Summary: random thoughts
X-Submissions: [e-mail]

Submitted-by: [e-mail] (Andrew Hume)

    i wanted to add some commentary to stephe's treatise (epic? opus?
kidney stone?). rather than trying to coherently fit my thoughts to his
story line, i thought it better to just dump them out. i therefore
assume the reader has the jist of what stephe said in his or her head
(and like me, is listening to Front 242 or the Sex Pistols).

    first of all, i think LIS are a good idea. as some of the readers
of this group know, i am the technical editor for an ECMA standard on
file system formats (its now DIS 13346!!). i ``had'' to change the draft
to follow essentially a thick/thin binding format. what this meant was that
there were prose sections that defined the semantics of the standard;
for example, how logical volumes were connected to volumes and volume
partitions. these prose sections by and large mentioned no field names;
for example, logical volumes have identifiers -- it didn't say what the
field name was. this prose section corresponds to the LIS; the descriptor
formats (in the latter part of the draft) corresponds to a binding to
specific descriptor formats (or the thin binding). i objected to this
in the beginning but by the end, i was a staunch advocate. it really
helps root out spurious details and you get a much better logical
consistency in the overall design. But, there are a few field names in
there because to get rid of them would have signficantly hurt the readability
of the standard; i was not willing to do that just for pedagogy's sake.

    i have been involved with a few large projects within at&t
(and outside at&t) and like most observers, have noticed an inevitable
trend for the methodologists to take over. admittedly, you need some
administrative goo to manage a few thousand programmers, but you know
that things have gone way too far on the day
you go to a meeting and someone SERIOUSLY suggests forming an ad hoc
group to meet in order to develop ground rules for a (yet-to-be-formed)
committee whose job is to develop a methodology for writing a project
proposal for the WORK that the original meeting decided had to be done.
i have called this the triumph of process over product.

    to a large extent, this has happened to the posix committees.
someone has a good idea: ``test methods''! so far, so good. encourage
people developing standards to think about them. so far, even better.
develop a standard way to write them up. so far, even betterer.
suggest to some over-arch-steering-bignose committee that they be made
mandatory. plausible, if not wise. committee accepts this idea. BIG
MISTAKE. put in more stark terms (and far less diplomatic terms than
stephe did), the question really was 'should test methods be compulsory
when we're not sure how far they can go, they will delay every useful
posix standard from 1-3 years for NO technical gain, they combine
in unpredictable ways with another experimental idea (thick/thin bindings),
and will probably drive 30-70% of the skilled volunteers out of the
standards process because of the huge increase of arbitrary BS such
folks would have to wade through just to stand still?' (actually, even if
put in such terms, it might have got through anyway because the
people on such over-arch committees TEND to be more concerned with
``purity of essence'' than with ``timely, useful standards''.)

    again, as a practical matter, my file system committee several times
voted against certain additions or changes because the nominal improvement
did not justify another draft or slipping the finish date by a month or two.

    this is not to say that you should get a standard out quick and dirty.
however, for the size of standards that posix works on, you WILL have
mistakes. so live with it, stop polishing turds and get the bastard out.
particularly for some of the older posix commitees, it would have
made much more sense to get the original standard out and get some experience
with it in the field while you dick around doing the thick/thin stuff.
it all has to be reviewed in 5 years anyway; for some of these documents,
that is nearly the MTTTT (mean time to thick/thin) and might be less than
the MTTTMTT (mean time to test methods & thick/thin).

    as a final comment, the committment to attend meetings is a
significant drain on smaller companies (especially individual consultants).
if someone told you that you had to get to meetings for an additional
two years because some watery bint had lobbed a methodology at you,
you'd think they were crazy. again, don't rush things but you gotta
understand that a standard is no good to anyone while its in committee.
seriously, if i were involved with a draft that was just about to go
out for (near) final ballot and someone said do test methods first,
you have just lost me as a future standards volunteer. either i give up
in disgust immediately, or i put on a hair shirt and get the job done
and then give up forever because i was so pissed off.

    i have had a fairly pleasant experience working on my standard.
i am disturbed that it seems a singular experience; everyone i talk
to about their experience (almost all posix) has at best an unhappy
experience; some, like stephe and others, have had terrible or worse.
my prayers go out to them.

            andrew hume


Volume-Number: Volume 29, Number 91