One of the things I like about being the lead programmer on a game is my exposure to architecture. This is something most programmers don’t get to experience very often and I enjoy it.
Architecture is difficult because it’s high level planning. Like all high level planning you deal with unknowns or partially knowns. The human brain is designed to skip over the flood of small details we encounter constantly through our senses so it’s definitely a learned skill.
Some people propose doing very detailed architecture. I disagree with this because, at least for me, it’s impossible to come up with detail that solves all useful cases. While a high level architecture is beneficial, once you start thinking at a function level there’s just too many mistakes, wrong assumptions, and forgotten cases to be usable as a spec. We’ve all seen cases of architecture that causes bloat but doesn’t solve any real problems. This is a fundamental problem caused by a detailed architecture with wrong information.
The approach I try to use is to first think of any obvious cases where architecture is necessary or beneficial. For example, I know that the client and server will both need shared code. So I split the project up into client only, server only, and shared. However, in other cases it’s harder to tell. When I pass a data stack between states how much architecture should I put into it? Is it worthwhile to put the stack structure in the state itself to avoid copying the data on state start? Should I handle memory allocations automatically or should I handle it per-instance?
I don’t know. So once I solve the high level problems I can accurately think about, I just write the code using the simplest case possible. Every so often I try to take a break and think back about what I did. If, armed with new knowledge, I think of a better way to approach the problem I refactor. This is also what extreme programming proponents advocate.
Refactoring throughout the day takes discipline and can be annoying because it involves rewriting a lot of already working code. However, if I don’t do it the program will quickly become unmaintainable.
As I gain more experience I think I get better about seeing the cases where I should think about planning ahead, rather than at the planning itself.