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

[Curt Sampson <cjs@example.com>]

On 2009-10-28 11:26 +0000 (Wed), Josh Glover wrote:

> Two years on, I still agree with Steve, and this is the crux of my
> argument that it is hard to scale agile practises across geographic
> locations....

I've never disagreed with that. 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.

> The trick seems to be having small, co-located teams that produce good
> documentation of the sort Steve describes as part of their sprint
> deliverables.

If you've got a small, co-located team, you probably don't need
nearly as much of that documentation as you might think. I do pretty
large and complex projects with a whiteboard and a few text files as
documentation.

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.

You can't get away from the fact that, if you're not executing your
specification, you're executing another specification that may or may
not be the same as the first one.

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

By the way, don't misinterpret this as me saying you must never have a
specification outside of code. Sometimes, for various reasons, you're
forced to code in a language entirely unsuitable for expressing a
specification (though it does so anyway), in which case you may be
forced to the inferior model of two specifications, one in a language
suited for the specification, and another in some other implementation
language that the compiler builds or the computer runs or whatever. But
if you're doing that, you should know why you're making that trade-off,
what you're getting in return, and should be looking for a way fix that.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com