Here’s a recent quote by Anna Marsh on Games Brief:
The key thing is that documentation produced needs to focus on being a practical manual for the team to work on, minus any marketing gloss. To make a comparison with architecture: During the planning phases of a building an architect might prepare Photoshop visualisations with happy pedestrians and sunny skies to show the public and financiers what the final building will look like. But they’ll also prepare far more precise blue prints, plans and technical documents for the actual builders.
Later in the article:
The more experienced the designer writing the documentation, (probably) the less changes you’ll need to make in development.
Humans look for ways to simplify things, often creating models in order to help them achieve things without being destroyed/distracted/confused by the complexity of an undertaking or a system.
To me the quotes above don’t seem any different from waterfall methodology used in software project management.
Read this …
… to see how amazingly bad it was as a methodology.
Architecture as a model for digital development projects, is so attractive because it looks like everything is incredibly certain, it pretends that there is order.
I think you’d be better of with pretending it’s a battle.
Imagine creating a document that laid out exactly what each soldier would do when he encountered the enemy … probably not that useful.
Now you could argue that Anna Marsh (and Games Brief who presumably endorse her) have more experience in game making than me, but they certainly don’t have more experience than me with start ups or software development, so until I see evidence that game making works completely counter to other software development, I’m going to continue with a more agile/iterative methodology.