Re: [tlug] [OT] Good IT Resume

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > > In other words, a specification is something that the customer can
 > > understand.
 > 
 > Can we revise this to, "a specification is something that the customer
 > thinks he understands?"

No, that's side-stepping the issue.  In the words of Sam Woh[1], you
want the spec to "be nice, precise, and concise".  But if the customer
(or their technical rep) doesn't grok it, you have to speak in an
imprecise common language and somebody has to bear a fair amount of
risk due to the imprecision.

 > Or possibly not even that. Many's the time a spec has started to get
 > complex and the customer has arm-waved and said, "you take care of
 > it."

And then what do you do?

 > My solution was to create a language more suitable for describing
 > the FSM, and make it parsable and checkable by the computer. [...]
 > When you do this there can often be issues with the client in
 > bringing him to understand what he wants to do and work out the
 > inconsistencies, but in the end, if the client wants something
 > logically impossible, what can you do?

Brings to mind the Army Corps of Engineers slogan: "The difficult we
do at once.  The impossible takes only a little longer."  Of course,
you can't actually *do* the impossible.  What's left is what us econ
nerds call "constrained optimization" or in even more ambiguous
situations "multiobjective optimization".  Simply put, the fine art of
compromise.

 > > Other formal notations, such as BNF, are rampant in RFCs. *But*
 > > eventually you have to tie things to humans.
 > 
 > If your point is that most humans don't read BNF, or even if they
 > do, learn terribly well from that, I'll agree with you.

No, my point is that the map is not the territory.  Humans generally
know what they don't want very well, and as soon as you deliver it
they can point to it and say "that's exactly what I don't want". :-/
Connecting formalism (or any language, for that matter ) to "reality"
is a very tricky business.

 > But building artifacts for pedogogy is done from a specification:
 > those artifacts are not the specification itself.

A legal contract is a specification, and if you don't believe it, just
wait 'til the judge tells you to fulfill it or pay damages and do jail
time for fraud.

 > Given an informal description of a language and a BNF, which do you
 > think has a better chance of getting two separate developers to
 > write code that does the same thing?

The BNF, of course.  But you're asking the wrong question.  The right
question is, "Which do you think has a better chance that at least one
of the two developers will write the code the customer wanted?" :-)

My answer is, give me five minutes with the client and then I'll
answer.  I'm pretty sure that's your answer, too. :^}

 > Your HTTP story was interesting, but seems to me to reinforce my thought
 > that the HTTP spec is a pretty horrible piece of work that relies
 > far to much on prose and not enough on formally describing what the
 > heck to do.

You mean like RFC 822's specification that Reply-To is an author
header, which is universally honored in the breach by ignorant admins
like Josh?

 > in an earlier version by relying on prose to say what they thought
 > the response code meant, rather than indicating what the browser
 > should do, we ended up with varying behaviour all over the place
 > and a backwards-compatability mess.

Well, first of all I'm surprised that you think that an RFC would ever
try to specify what a browser does with a response.  RFCs specify wire
protocols, not agent behaviors.

 > BTW, from what little I understand of your situation, my initial
 > reading of RFC-2616 indicates that using 501 for your situation is
 > rather stretching the use for which it seems to be intended. You'll
 > note that every suggested use of 501 in the spec is for a case where
 > limitations of the server's implementation of the protocol prevent it
 > from generating a response; in your case, it seems to me, the server
 > would be perfectly capable of generating a response if only it had
 > the appropriate data.

But the archive *does* have the data.  If the mailing list wishes to
support the guaranteed unique URL protocol, it adds a header to the
post *before* giving it to the archiver.  It really is a question of
the server implementation, although not a question of the httpd
implementation.  We want the browser (and in particular we're thinking
of specialized browsers that know about conforming mail archives) to
retry with the message-ID namespace in this case.  On the other hand,
if you do implement the list-uuid namespace, then you don't want to be
getting a message-ID query every time a list-uuid fails: "I already
told you I don't have it, dummy!"

 > Oh, if only the writers of rfc2616 had taken the next logical step of
 > specifying what the browser should do when it sees each return code....

As I wrote before, the RFC would have been rejected if they tried to.
That's why some standards are published by the IETF and others by the
W3C.


Footnotes: 
[1]  Famous San Francisco restauranter.  If you don't finish giving
your order in ten seconds, he spends the next five telling you what
you're going to eat.