I'm quite certain just about everybody these days realizes how bad 'waterfall' is. Even at college they teach not to, and that's telling, as education normally lags 10 years behind the best ideas.
I'm not saying everyone should use it, but I've been a part of teams where the Waterfall model has been used successfully.
That argument works both ways - if it's not straight forward, what makes you think you can come up with perfectly formed design out of your head with no practical feedback?
Sometimes you miss large issues just sitting down and coding, until it's really far in. Then you either need to live with a bad design or go back and re-write large sections. Designing first can potentially allow you to highlight those issues and get them solved, earlier. But only potentially.
To help answer the original question, I'm in the mindset that lots of existing technology and design patterns can be applied to games. So I'd recommend just buying a copy of Design Patterns
. I personally have applied some of the patterns taught in that book in my own games. For example I often use a Singleton for handling music and sound effects.
Architecture wise; I only have links about multi-threaded architectures. There is a brief overview of three different designs on Gamasutra
, another mult-threaded engine on Intel
and some slides about Id Tech 5
where towards the end they talk about how they structured their multi-threaded code.