Mental Debugging

It's surprising how often my mental model of something is severely buggy. (Well, surprising to me.) I think I know exactly how to do something, but when I sit down to code it (or, in some cases, actually do it), I inevitably find that the situation is much more complicated than I thought. No matter how hard I think about it before hand, I have to make major changes before I can get real results.

Plate tectonics is a perfect example. My first instinct was that I knew a simple way to make a plate tectonics simulation, so I was surprised not to find one out there already. But when I tried to write my own, I didn't get very far before running into big problems.

So far, the only effective way I've found to debug my mental models before beginning to code is to do a couple of iterations of a simulation beforehand with paper and pencil. In most cases this immediately makes obvious the questions you should have answered before you started coding, such as "What do I need to keep track of?", "What data structure am I going to use to represent this?", and "How is the program going to know where two plates are colliding?". This forces you to clarify the vague parts of your algorithm and identifies major structural changes needed, before you've wasted time writing code that can't be used.

But the ultimate way to debug your mental model is to write code that implements it. Before you do that, you've got no way to know for sure that your ideas don't have bugs, or even gaping holes, that you simply haven't noticed.

Maybe I should add a corollary to the third law of computer programming?

Third Law of Computer Programming:
  Any programmer can find 90 percent
  of his bugs simply by explaining his
  program to any uninterested observer.

Corollary Two:
  To find the other 10 percent,
  you have to write the program.

Running a couple of iterations with paper and pencil beforehand is like explaining it to an uninterested observer. (In this case, the programmer.)