Using version control and frequently checking in your changes (I'm thinking several times a day, not a big checkin once a week) will allow you to pursue avenues

Using version control and frequently checking in your changes (I'm thinking several times a day, not a big checkin once a week) will allow you to pursue avenues of exploration, possibly realize they are dead-ends, and roll back to an earlier state with no difficulty. This can be really liberating. Don't worry if they are non-working checkins (do those on a branch if you want), just make sure you have preserved significant stages in case your subsequent work doesn't pan out. Implementing some form of "print myself" function (operator<<, I think - it's toString() in Java) on each object in your data model, so you can see something within a debugger, beyond the usual "object at address 0xDEADBEEF" type of information can be very helpful. Since you are working on a program in a well understood domain (chess), there is a lot of available data (PGN databases) and a number of other implementations. I think it would be worth spending some time building some scaffolding that will let you take advantage of these for testing. For example, if you are building a move generator, you can build some harnesses that will take libraries of PGN games, and use your move generator to successively generate the candidate moves for each move of each game, and make sure that the move that actually followed is one that your move generator is capable of generating. You can also build a harness to compare your move generator's candidate moves to another implementations', and make sure that they agree. This kind of thing can take a long time to run, but if you set up some continuous integration kind of thing to do it continuously, asynchronously, or to do it overnight, you can catch some problems early enough that you can handle them more gracefully than later, especially if the cause is ultimately the object model - you want to fix that before you build lots of code that depends on it and is resistant to changes. I'm not sure whether this is as easy in a non-GC language, but I've found using immutable data objects makes many things more easy to understand. I'd seriously consider making a position (a particular state of the chess board) be immutable, and applying a move to that position produces a new position instead of modifying the position. The functional language literature has a fair bit to say about the benefits of this approach with respect to understanding what a program is doing at any given time.