in reply to OT - How to deal with coders who don't do what they should
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.
|
---|