You're Not Done Yet

From AndrewMoore

When painting, they say that the most important part is the prepwork. I'm starting to think that in software, the most important part is the stuff you're supposed to do after you think you're done. I get pretty excited that I've written a new piece of software or a new feature, and forget to do all of the boring stuff afterwords, like documentation and such. I used to have a note pinned to my cubical wall to remind me of all of the things I usually forget. I don't have a cube anymore, so I built this list.

• Make sure the full test suite passes. Sometimes I just run a portion of the test suite while I'm coding. It tests the features closest to the code I'm working on. I should run the full test suite, including the documentation correctness and coverage tests.

• All the methods that you touched need to pass coding standards tests. In some projects I work on, Perl::Critic tests and perltidy tests are part of the test suite. Sometimes, this is a separate step. Anyway, don't forget it.

• All the methods that you touched should pass the documentation tests. I usually have two of these: pod coverage and pod correctness. Sometimes they're part of the official test suite; sometimes they're not (yet).

• Record this activity in your emacs planner (or whatever you use). If you're doing this work for someone else, it's just good practice to keep a log of all of the work you do. I use Emacs planner-mode.

• Document the decisions on the wiki. You made design decisions, implementation decisions, and all kinds of decisions while writing this feature. Document that for your users, system administrators installing your software, for your coworkers or contributers, and for yourself when you come back later.

• Alert the requestor that you're done. Someone asked for this feature. Let them know that you're done. They'll often tell you that you're not.

• Close the RT ticket. Or the bugzilla bug or whatever.

• If it was a bug, answer these two questions:

1. How could you have prevented that bug?
2. How could you have automatically detected that bug?

It's by answering these two questions that you go from making your software incrementally better to making it exponentially better.

I find that running through this checklist helps make sure I'm actually done when I think I'm done. I find that I'm typically Not Done Yet.