Abstract :
Getting features right isn´t easy, whether you try to get them all right before writing code or approach each one as you go. It´s tense work, much like contract talks. It starts out well enough: the customers describe what they need, and the programmers estimate the cost. Before long, though, lack of trust creeps in, and each side withholds information from the other. As a means of defense, the programmers demand precise, unambiguous statements of the requirement. When the customers try to provide them, they end up expressing their needs in complex, run-on prose. No wonder the requirements are mostly full of holes. Rather than fill the holes, the programmers usually try to meet the requirements as best they can, misinterpreting them along the way, and the result is software nobody wants. Examples help both with complex rules, which are difficult to describe with prose, and with simple rules filled with jargon, whose terms are easy to misinterpret. So the next time you´re not quite sure what your customer means, ask for an example. It´s the most effective technique to avoid building the wrong features.
