I found this funny: Structured Procrastination (linked via Brian Marick’s blog). If you want to get the gist of the article, just put off reading it by finding something productive to work on :-).

In fact this kind of reminds me of TDD. You can procrastinate on the big problems by implementing all the little tests for the features and behaviour you understand well. As you do this you end up discovering parts of the big problems that are easy to solve, or at least learning more about the requirements and are better placed to solve the big problems. By the time you get to tackling the big problems you find that there aren’t any left – they have been reduced to fairly simple tasks. You have actually been fairly effectively applying a divide and conquer strategy.

The procrastination thing also ties in quite well with the ”lazy programmer” concept.

Yes, I am quite aware of the irony of this post. :-)