Working on my own project, without the usual constraints of detailed requirements and specifications, I get a lot of freedom in the methodology I use.

   

This means that I can focus efforts a little differently - As long as the available development time is being used productively I don’t really care what tasks are being done or how long each one takes.

   

This approach leads to last minute design and minimal specifications, which isn’t as bad as it sounds. With plenty of other stuff to do, spending less time writing documentation suits me just fine, and flexibility of design is usually a good thing.

   

The one thing you need to be careful with when running a project this way is making sure that your developers can handle minimal specifications. I have in the past worked with developers who thought that the correct response to an unclear requirement was to stare at the screen for three weeks until someone noticed. Fortunately this issue is reasonably easy to avoid. The best way is to only hire perfect developers, but failing that you can do reasonably well just by making sure you know what your developers are doing.

   

While I don’t advocate micromanagement - giving developers the impression they are not trusted is a really bad idea - you should be reading the code that gets checked in. Don’t expect the code to be perfect, but look for places where there is a mismatch between what the developer thought you asked for and what you thought you asked for.

   

Being a couple of weeks into the project, I’m getting a good feel for what works. Initially we tried a more conventional spec, but with very little detail. That works ok to start with, but building the right thing beyond the most basic level requires either more detailed documentation, which would take too much time, or knowledge of the complete system, which you can’t expect from someone new to the project.

   

From there we have been trying a more test driven approach, which has been working quite well. Initially we tried the minimalist approach, creating the test methods but only populating them with comments. That didn’t work all that well, since the comments left too much flexibility in how to implement the tests when the developer doesn’t know anything about the UI the tests are simulating. It also means needing a thorough review of the test code rather than just running the tests and looking over the code briefly, which is more time we don’t have.

   

The tests written as specs need to be quite detailed. Writing the detailed tests does take more time, but it’s not too hard to write them once you get a good template set up. We’ve been making heavy use of Visual Studio’s generate method stub feature, though unfortunately that doesn’t work for extension methods, which we are also using a lot of.

   

Once the tests are set up, getting the right code written is easy, and writing the tests is also quite helpful for working out details of the design that would be overlooked with a written spec. If the tests aren’t ready we fall back to the minimal written spec so no development time is wasted, though we do seem to be running out of places that will work.