Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Tue, 31 Jul 2007, Stephen J. Turnbull wrote:

> > come up with a more formal description that would be more amenable
> > to a formal proof of correctness and interpetable by a computer,
> > both of which are indisputably Good Things.
>
> C'mon, man, I'm a social scientist, you can't fool me with that
> nonsense.  Both of those are good things, but in general irrelevant to
> the specification problem, which is the problem of tying human wants
> to physical reality.
>
> 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?"

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." Your Z-code/security expert story is a good example of that, and
exactly what I do in many situations: write down "make it secure" on an
index card, which is the customer's "specification," and do the "real"
specification out of view.

Moving on, I perfectly agree with the phrase, "tying human wants to
physical reality." That's where, in fact, I think that getting more
formal with the specification can help.

For one particular client, I remember the specification they came up
with was quite evidently one for a finite state machine. ("In this case,
do this, in that case, do that," etc.) This spec had been allegedly
implemented for some time by the time I stepped in, but not terribly
successfully; bugs were constantly cropping up, and nobody ever really
knew if the thing worked as it was supposed to or not.

The problem, as it turned out, was that the specification was
unimplementable because it had logical inconsistencies in it. These
were very hard to detect due to the way it was written (as prose in an
Excel spreadsheet). My solution was to create a language more suitable
for describing the FSM, and make it parsable and checkable by the
computer. That let us get rid of the inconsistencies, and as an added
bonus, also relieved us of the burden of translating the spec into an
implementation: the spec was the implementation.

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?

> 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. But building
artifacts for pedogogy is done from a specification: those artifacts
are not the specification itself. 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? Which is
the spec, and which is something to describe the spec to someone?

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. The whole 302/303/307/GET/PUT mess is a perfect example
of that: 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.

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. Note that in particular, a 501 may mislead the
client into thinking that it can modify the technical details of the
request apart from the URI (such as the method, content-range or
transfer-encoding) and try again.

There doesn't seem to be a code for what you want, which is, if I am
interpreting your problem correctly, "we don't support that URL, but
other mirrors might, though I don't know who they are." For this, it
would seem to me that your best bet is a 404 with a body explaining the
problem to the user.

(But that's a suggestion; my practical opinion is that it doesn't really
matter what the heck you return, the protocol is so broken.)

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

But then again, what can you expect from folks who can't even spell
"referrer" correctly? :-)

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com