The way I (try to) work has been inspired a lot by the XP (eXtreme Programming) folks, who insist that code that doesn't directly help your program do something it has to do is code better left unwritten.

The principle is that you start with a description of what the program does for the user (well, its interaction with the outside world, anyway), as described in "stories". You then proceed to describe your system from the point of view of making only the program artifacts (objects and classes) that are needed to accomplish the tasks described in the story. You don't write any code that isn't used.

And you start by writing test cases, before you write code (so that you'll know when you get the code right). You elaborate the tests and the code until you've met the requirements in the stories.

And you continuously refactor. Don't worry about making the right architectural decisions on your first page of code. Just change the structure as you go along to meet your new discoveries.

As far as reusability, well, a great quote that I heard (sorry I can't attribute it right now) is this:

Nothing is really reusable until it's been reused three times.

Why three times? Because it usually takes at least that long to get a feel for what other users of the code might need. Don't start out by writing a framework; start out by writing an application that works. If you find that you need to reuse some pieces of it, refactor as necessary to do so. Repeat. Don't be afraid to totally change the structure of your software.

Some links to XP resources:

• http://www.xProgramming.com/
• http://c2.com/wiki?ExtremeProgrammingRoadmap
• http://www.extremeprogramming.org