Evolutionary prototyping with a spike and stabilize style. Write a first version/prototype, to flesh out the details. See if it's even useful. Figure out where

Evolutionary prototyping with a spike and stabilize style. Write a first version/prototype, to flesh out the details. See if it's even useful. Figure out where the tricky parts are. Perhaps tear it down and write again. More likely do some wholesale reorganization. Let it sit for a while. Use it myself figure out what's missing. Go through again (this is now #3) and fix the problems, further organize the code, get friendly users to test it out and report what real users need. (I'm a sole developer with no QA.) Start writing functional tests. I don't like unit tests as I think they are too low-grained and inhibit larger-scale rewrites. This usually resolves the final architectural issues. Then use coverage testing to find out I've only got 80% coverage, so add those. These usually involve error handling, like input files in the wrong format. (I make sure to write that code as part of development, because that's when it's easiest to think of possible input errors. But I don't write tests for them because the parser and even the supported format might easily change over the iterations, making tests a waste of time, when I know even simple line-based coverage testing can identify what needs to be tested.) Then write the end-user documentation, which usually teases out a few more issues. If I can, put it aside and come back to in a few months later. Seeing it later with fresh eyes helps as a code reviewer. I've got 14,000 tests. Takes about 45 seconds to run the main tests. The full tests include some very lengthy tests that I rarely run.