To me that seems like it would be an overwhelming burden before starting a game, and would prevent you from ever doing anything new and interesting in your games as you try to figure out every detail before even getting something playable. I think it would be better to try something new and follow the fun.
I often see this objection from newer/younger/less-experienced developers. Nobody is advocating that you work out the literal code of your whole system before you type it in. I also think that sounds like a huge, boring waste of time. What Norman (as I understand his message) is saying (and I agree with him) is that, assuming that you have a vision for your system/game/app/project; i.e. you're presumably embarking on your project because you've had a great idea and you want to make it real, then you're going to want to work out, in advance, what the primary systems and subsystems of your project are going to need, how they're going to connect together, how data is going to flow and so forth. You're going to want to build a strong mental model of all of the primary moving parts of your application, and in going through this process to build up your model, you're going to hit countless things you haven't thought of that would have messed up your architecture too late to fix easily, had you started coding straight away. These will include inefficiencies in your initial approach, deeper requirements that you didn't realise you had, cases where your initial assumptions turned out to be completely wrong, etc.
I'm not just parroting stuff I've read somewhere, I've been there. Countless times in my career I have started coding with little-to-no plan, and have worked in environments where that was the approach, and it is almost always a fantastic recipe for coding yourself into a corner and screwing up the project. Think of all of the failed projects; the games that got released after huge delays (if at all) with way more bugs than there should have been, the huge government and corporate website and intranet projects which went millions of dollars over budget and came out as a steaming pile of broken crap, and all of the indie projects which started out great and then ended up being cancelled or tossed in the "developer has lost interest" pile due to the immensity of the problems that the developers created for themselves.
I have been there and done that, over and over again. I've learned the hard way, and it changed my approach over time. And it's really not anywhere near as hard (or as unfun!) as you might think!
Screw design documents. If you have a large team and publisher-imposed deadlines, or you need VC buy-in or whatever, then sure, go the detailed, official design document route, but for yourself? Keep it simple and employ a divide-and-conquer approach. My approach is actually somewhat analogous to the widely-accepted, age-old process called "critical thinking". Yes, I also used to think that was just a term that meant "thinking about stuff carefully and without bias". It's more than that and there's actually a process, but I'll leave that to you to Google, if you're interested.
Anyway, start with bullet points and words. Write down a few sentences that you think explains your game to someone you're pitching it to. This may sound boring, but it's only a few sentences and it's kind of a catalyst that switches your brain from "shutup and let me code" mode into a more thoughtful, ready-for-brainstorming mode. If you're so inclined, you may expand this to a few paragraphs. In the process of doing this, your ideas tap is going to start to flow, and there's nothing you can do to stop it. And once it starts flowing, you're almost not going to be able to write fast enough to keep up with yourself. It's an enjoyable process, trust me! I have lost countless days to this process on numerous occasions just because I was so deep in design, trying to figure out the details of what I was trying to do.
Next pretend that this person you're explaining your game to is a developer who is contemplating working with you on the project, but wants to know more, so start putting down a few bullet points just quickly outlining the primary components you're probably going to need to include, and explain what those components do in a way that if you came back to it a month later (because hey, you got distracted with something else, or got a boy/girlfriend or something) then you'd be able to read through your notes, understand what you were trying to do and continue where you left off. Think about your game in terms of the data if you can. Imagine what sorts of data will exist in your game, and would need to be processed if your game were just a simulation of your idea, with graphics and inputs and stuff to be implemented later. Doing this will help you to separate minor implementation details (which you're not going to bother with until you're coding) from the actual logic and underlying architecture that describe the raw game itself. As a quick example, you might think of your player's spaceship as a sprite, and it needs to respond to input and then you'll think about key mappings and that sound effects will need to be played, etc. This is the wrong way to approach things. Instead, think about the spaceship in terms of its data. How big is it? How fast can it go? Can multiple players be on board? What sorts of upgrades and modifications can be performed on the ship? Can it dock anywhere? Can players get out, or is the player the ship itself? What other sorts of attributes might it have? Expand this to the other things in your game. What sorts of interactions with other game entities are possible? Why do you even want those interactions to be possible? And so on.
By now you should have quite a few bullet points and they'll probably be quite disorganized. That's fine! Every time you write down an idea, one of two things will be true. (1) you're going to already have a detailed mental model of exactly how you're going to approach it in code, and I don't mean line-by-line, I mean conceptually. If you were to sit down and implement this feature right now and you don't even know where to start, then you probably haven't thought about it enough in advance, which brings me to point (2) you don't really know how you're going to approach this just yet; you may have no idea at all, or maybe sort of a hazy concept of how you might go about it. If this is true, then hit the tab key for your next bullet point (you're indenting it from the idea bullet point you're breaking down), and literally write the question "How am I even going to approach this?", and then start thinking of rough ideas. Write them down as bullet points. Every time you write down an approach, question it and try to think of a reason why it might fail. Write that down. If you think it's a good idea, write down why.
What you're doing is breaking your approach down and coming up with the architecture of your game. Every time you pose a question to yourself that (a) is not a minor implementation detail, and (b) you don't know the answer to, then indent, add a new bullet point and start breaking it down by posing the question to yourself "how am i going to approach this?". After you have done all of this, you're going to find that you very rapidly start crystallizing your game idea into something that you have a clear mental model of. You're going to have inadvertently hit many, many brick walls in advance of having done so in code, and moved beyond them in a very short space of time before having ever coded up the suite of classes and functions that it would have otherwise taken for you to realise the flaws in your own approach.
To all those who say "there are some things you just can't know before you write the code", I say that either you're just being argumentative, or you haven't adequately figured out the difference between implementation details and architecture. If you're hitting fundamental architectural problems in code, then you failed to invest in what would have been valuable time spent figuring out your architecture in advance. If on the other hand, your architecture is sound, but the problems you're hitting are at the implementation detail level, then you're missing my point. Take this as far as you need to know that your approach, across the board, covers that which you wanted to achieve up front. If your requirements change halfway through, then, well there's not much you can do to plan for that other than being careful to balance consideration of the "what-ifs" against venturing too far into YAGNI territory. If you don't have enough information to know whether your approach is sound, then research! Find out what algorithms are available that could be used once you start coding. Learn about some new data structures that could solve your problem. Write a few quick sample apps using the frameworks or libraries you're thinking of so that you can get a sense of whether or not you really want to use them. Read a few articles. Ask some questions on StackOverflow. "I didn't know that in advance" is not a good enough excuse for wasting three months coding something only to realise that your approach was fundamentally flawed and destined for grand failure.
Finally, if one of your requirements is that you want the freedom to evolve, experiment and change your approach as you explore, then fine. Plan for that. Ask yourself the questions "what sorts of ways could my approach hypothetically diverge from what I'm planning at the moment?" and "how can design my code in a way that will preserve the important stuff without boxing me in?".
Take a leap of faith and try this process this once (I mean properly - you should end up with pages and pages of notes at a minimum), and notice how good you feel having encountered and moved passed six months or more of roadblocks in a tiny space of time without having wasted the time coding to get to those realisations. Feel how great it is coming up with a theoretical model of your game that you now have a really good idea of how to tackle and what architectural requirements you're going to need to deal with almost before you've written a line of code. I know coding is fun, but please. Take the time. Trust me on this. Architecture is architecture, whether you're writing a game or a stock trading system. Get it as right as you can, before you start to code, and you'll save a huge amount of time and have a result you're a lot more proud of and which is a lot easier to maintain and extend.
That is all.
