Unit testing. Isn't that some annoying requirement that we're going to ignore? Many developers get very nervous when you mention unit tests. Usually this is a vision of a grand table with every single method listed, along with the expected results and pass/fail date. It's important, but not relevant in most programming projects. The unit test will motivate the code that you write. In a sense, it is a little design document that says, "What will this bit of code do?" Or, in the language of object oriented programming, What will these clusters of objects do?" The crucial issue in constructing a unit test is scope. If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions. Certainly, interactions of objects are the crux of any object oriented design. Likewise, if the scope is too broad, then there is a high chance that not every component of the new code will get tested. The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy.