As most of us know – but tend to forget in the most crucial moments – there is a subtle difference between getting things done and getting things done-done:
“Hey, Liz!” Rebecca sticks her head into Liz’s office. “Did you finish that new feature yet?”
Liz nods. “Hold on a sec,” she says, without pausing in her typing. A flurry of keystrokes crescendos and then ends with a flourish. “Done!” She swivels around to look at Rebecca. “It only took me half a day, too.”
“Wow, that’s impressive,” says Rebecca. “We figured it would take at least a day, probably two. Can I look at it now?”
“Well, not quite,” says Liz. “I haven’t integrated the new code yet.”
“Okay,” Rebecca says. “But once you do that, I can look at it, right? I’m eager to show it to our new clients. They picked us precisely because of this feature. I’m going to install the new build on their test bed so they can play with it.”
Liz frowns. “Well, I wouldn’t show it to anybody. I haven’t tested it yet. And you can’t install it anywhere—I haven’t updated the installer or the database schema generator.”
“I don’t understand,” Rebecca says irritably. “I thought you said you were done!”
“I am,” insists Liz. “I finished coding just as you walked in. Here, I’ll show you.”
“No, no, I don’t need to see the code,” Rebecca says. “I need to be able to show this to our customers. I need it to be finished. Really finished.”
“Well, why didn’t you say so?” says Liz. “This feature is done—all coded up. It’s just not done done. Give me a few more days.”
On the one hand, we got developers telling you the feature is done while there are still some crucial steps left. The feature might still be buggy or not yet tested, or it just works in a local sandbox – but “the code is done!”
For reminding myself again and again how to really finish a feature, I created a wrap-up checklist that is available at my Grab Bag of Useful Stuff. The list summarizes all steps I adhere to after my code compiles and runs, but before it is committed to version control, such as writing unit tests and API documentation. The checklist has been mandatory at my company for a few weeks now, and it increases code quality and uniformity by a great deal.
On the other hand, some engineers tend to overdo it. Optimizing your code saving every tiny bit of CPU time and memory should never be your goal unless you’re working on very critical parts of your code base. Clearly, most of your code will never be performance-critical anyway, because it’s event-driven or even just used once at initialization. Try and focus on getting the job done, and start optimizing as soon as it’s really necessary.
Oh, and should any project manager or lead programmer ever happen to ask you how long you’ll need for the implementation of a new feature: Please tell him your guess for getting it done-done 😉