in reply to OT - How to deal with coders who don't do what they should

You didn't indicate how you communicated the objectives to the programmer. I'm guessing you did so verbally, and am further guessing that you didn't specify acceptance criteria (i.e., "when you're done, this is how you'll have to prove to me that it works").

A bit problem with one-time verbal instructions is that it's too easy to hear enough of them to get your mind latched onto a tempting problem, at the expense of the complete requirements. You've gotten the problem halfway explained, and their minds are already racing ahead towards crafting the perfect regular expression/using some new CPAN module/whatever. Happens to me all the time.

So follow up with an email, laying out the objectives, including what you'll look for in a solution (i.e., acceptance criteria). I've found that it often helps to throw in additional context, such as some notes about who will be using the result, and what their usage pattern is expected to be. If you want to go a bit more formal, sketch out a Use Case.

  • Comment on Re: OT - How to deal with coders who don't do what they should