Re: [tlug] linux@example.com How many widely can we do that?

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

Curt Sampson writes:

 > But it's also hard (extremely hard, in fact) to write a
 > specification without bugs when you have no way of testing it
 > except thinking about it, and it's also very hard to keep an
 > untested specification and code in sync.

Burn that strawman and then we can talk.  Of course you have to write
code.  The question is, when the user posts a bug report, is he ever
right?  If there is a separate specification, he can be.  If the code
is the specification, he cannot be, by definition.  (But see below on
choosing versions of the reference implementation.)

 > On 2009-10-28 15:10 +0900 (Wed), Stephen J. Turnbull wrote:
 > 
 > > Yikes!  If the code is *the* (not *a*) specification, as soon as you
 > > make a change you have two specifications: the pre-change spec, and
 > > the post-change spec.
 > 
 > Right. As opposed to when you have two specifications, thus giving you
 > four at the end, two pre-change specifications and two post-change
 > specifications. Now you've got twice as much to verify.

Erm, no.  When you have a separate specification, you just don't
change it very often.  It's too expensive to do so.

 > > The problem is that if you have 1,000 revisions in your repo, you
 > > have 1,000 specs (or maybe a *lot* more if you consider the implied
 > > combinatorics of the patches). Don't you think that is too many specs?
 > 
 > Sure. You need to pick one as the current specification, just as you do
 > when you look back on that long list of revisions of that specification
 > you wrote in English.

Actually, no.  In the case of a separate written specification, a
particular one is typically agreed to be *the* specification with
clients of the code, and for that reason it's difficult to change, and
is almost certain to be the most recent draft.

In the case of the code-is-specification approach, it is almost
certain that the developer will chose the most recent version as "the"
specification, while the user will typically chose the version he had
before the upgrade as the "the" specification (and if not, he'll most
likely choose some unimplementable combination of the pre-upgrade
version and the current one).

There is a very important case where a separate spec is definitely
suboptimal, and it is not coincidentally a case where agile
development makes the most sense.  And that is the case of code with
interacts directly with non-technical (ie, non-IT-technical) users who
don't know what the fuck they want (or, more charitably, don't know
enough about IT to express it as an implementable spec), so the spec
has to change daily anyway.