[
Lists Home |
Date Index |
Thread Index
]
> I advise people who want to
> write specifications to stay under the radar until they have running
> code. Unfortunately, the lesson promoted is to get all the buy in
> they can before they have even gotten a solid team together. It's a
> bad plan. Jam first. Pick the band. Then rehearse like mad until
> you are ready to play a gig somewhere away from the target customer.
> Then cull the songlist and go get the money.
>
> len
It appears that "scale" aka "organizational size" is at the heart of
the problem.
A spec process for a small audience is easier to manage than one for
a large audience including all the heavy weights. Having more
participants means having more differences wrt. perspectives,
backgrounds, priorities, timelines, strategies, policies, etc.
Getting broad buy in and rough consensus before having running code
makes it more likely agreements and a spec will eventually emerge,
though it unfortunately also increases the odds for a spec that may
be bloated, fuzzy and ultimately of dubious quality and merits. On
the other hand, having running code first implicitly puts someone
into a dominant riding seat, and while it increases the odds for a
focussed quality spec, it reduces the odds for broad consensus across
many heavy weights. It's a difficult chicken and egg problem.
Ideally, the "running code" and consensus building process would go
hand in hand in parallel at multiple participants, and inform each
other continously. But that's easier said than done when working "at
scale".
Wolfgang.
|