RE: [GD-Design] Re: Design Documents

[Philip H. <ph...@me...>]

> Let's see.  Current stuff is under wraps, but here's a pretty good
> approximation

[Very useful example deleted]

Cheers, that's very interesting. I can certainly how this sort of approach
could work very well for games development (at least from the developers
point of view).

> Also, the feature card database is an idea database that many people can
> contribute to. We have a go-to person who makes sure the language is
> coherent, but other than that anyone can add their concepts.  Since the
> final product is derived iteratively from high priority features, there is
> no need to maintain the 'monolithic perfect design doc'.  Someone has an
> cool idea?  Add it to the database.  The prioritization and development
> process ensure that it is given it's proper due consideration.

I take it there's one or more people responsible for the overall vision of
the project? I've worked on several projects where the 'design' was very
informal but they suffered because there wasn't anyone who really accepted
responsibility for the design.

> The other realization is that many details in design docs are unimportant
> tidbits placed there by anal retentive world builder types. ;-) (I suffer
> from this myself)

:) Someone once said that a piece of writing isn't complete until everything
that can be removed, has.

> You are correct in assuming in that most of the knowledge is human
> knowledge, not documented knowledge.  The basic philosophy is "Record as
> little as practically possible.  Rely on the creative capabilities of your
> team combined with a common vision to fill in the details in a
> cohesive way"
> Most developers are not assembly line workers and it seems a shame to use
> them as such.

Does this approach go down well with the developers, I would have thought
most of them would love such a freeform, creative environment.

> Another way of looking at it: If your team leaves, no design document will
> save the project. :-)

:) And of course having a design document doesn't guarantee success even if
they don't leave.

> >>Do you also use the two programmer approach to Extreme Programming?<<
>
> Not yet. :-) A lot of the problems the XP guys say we'd have if we didn't
> use pair programming have indeed surfaced.  One of these days I hope we'll
> give it a shot.

That bit always struck me as a good idea which is very hard to implement. On
a similar note there are advocates of a 1 Programmer=1 Tester approach to
development (Microsoft used to use this, maybe still do) which would be
equally difficult to get approved by the people with the money.

Phil