In my personal blog I wrote about how the blank page syndrome can lead to procrastination. I gave an example of how it’s often difficult to know where to start when faced with a vaguely written bug report or an enhancement request. I suggested that one way to gain clarity is to skip ahead to writing the bug-resolution documentation as if you had already done the work. What will be the instructions to the end user on how to take advantage of this change?

Quoting myself, “Then, as I do the work for real, it gives me an acid test to know if I’m on the right track. In other words, does the software now work as advertised? A side benefit of this end-first exercise is that it often reveals latent issues and questions for which I have no answers. It also helps me to enumerate any assumptions that I’ve been making, which perhaps ought to be validated.”

This is a very much akin to Test-First Development (a.k.a. Test-Driven Development, or TDD for short), of which I am a huge proponent. I’d almost say that what I described above is a poor man’s version of TDD, except that there is no cost to doing TDD. Unit testing tools are free for the asking.