I think a more appropriate question is, "what sort of spec to you use for a given audience?" Different stakeholders can prefer their specs to be delivered in different formats (not that they always get to have it their way, of course).
Some might like specs in the form of wireframes for easy lo-fi visualization, some might like large printed documents for legal or contractual reasons, some might like pseudocode (or skeleton code), and some might think anything but working program is an unecessary waste-of-effort. The problem comes when you try to please them all with a single format. One size does not fit all (very well). I think Siegy's assertions would be better stated in a less absolute format. 1) Specs _can_ help a developer, but they can also confound them if not written correctly. 2) It _can_ be easier to update a spec than to rewrite code, but it can also be easier to rewrite the code than it is to update the spec. 3) Specs _can_ serve as a starting point but they can also get out of date and do more harm than good if not cared for throughout the project. The trick is to know what works best for the project you're working on and the environment in which you're working. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posted from the new ixda.org http://www.ixda.org/discuss?post=46833 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
