Forgive me. I seem to be feeling particularly ornery right now, but this stuff touches a nerve..
On Fri, Oct 16, 2009 at 9:42 AM, siegy adler <[email protected]> wrote: > I’m an advocate for writing functional specs. Here are 3 reasons why I > believe specs facilitate development of Websites and applications: > > 1) Specs serve as the blueprint for the developer, which enables them > to review the project and start coding without delay. Would you build > a house without a written plan? > Seriously, the mapping of software creation to building construction needs to stop. If I could find the person who first suggested this metaphor, I'd shove them into a wormhole. > 2) Specs that are reviewed/approved by project stakeholders help > ensure that the finished product meets expectations. If you mean functional spec as you said above, then no, absolutely not. I'm sure there are exceptions and people who are using a soft tissue lens on their memory, but stakeholders--normal people in general--will rarely be able to imagine a system based on a functional spec, and even if they do, chances are it will be different from what you and the others on the implementation team have in mind. This means it will be a total crap shoot in terms of whether or not building to a functional spec "meets expectations." This is a widely shared sentiment in the software community based on tons of bad experiences relying on functional specs for shared understanding. If you have a fully functional prototype that simulates the end product as a spec, then maybe your statement comes close to be tentatively true. Otherwise, no way. > Isn’t it easier > to update a spec than to rewrite lines of code? > Not if your spec is code. ;) Not if you go through endless spec revisions because people can't use functional specs to come to a shared imagination of what they envision the system to mean. Not if you bother writing the spec, revising it several times, and then have to change the code anyways (and then probably have to update the spec again to match) and then repeat this many times throughout the project. > 3) Specs also serve as the starting point for the development of use > cases, which streamline the QA process. Wha wha wha??? I'm in shock.. give me a moment.. did you say a functional spec is the starting point for the development of use cases? Oh dear... Even if you do write a functional spec, it should be the *product* (i.e., comes out of/after) the understanding of (and, if necessary, documentation of) use cases. The *stories* come first. End of story. > How else are the testers > supposed to know what to expect when a button is pressed, etc.? > If the interface doesn't make this clear, you failed. If you're starting from a functional spec, I'm not surprised this is a problem. Think about it this way. If someone who is, theoretically, as computer and system savvy as a QA tester can't understand from your interface what is supposed to happen when a button is pushed, how in tarnation are your users supposed to figure it out? Are you going to make your users read the functional specs in order to interact with the system? > I can’t think of a good reason not to spec. Can you? > Because it is a waste of valuable time for everyone involved that makes people 1) falsely believe they have a shared understanding, 2) forces you into a function-centric thinking rather than a human and experience-centric way of thinking, and 3) ultimately causes this wrong thinking to seep into the interface and results in stereotypically bad software from a human perspective that not only does not meet expectations but actually is worse than the worst they could have imagined had they tried to imagine a system as far away from their expectations as humanly possible and still resemble in some wraith-like form the functional specs they thought they read three years ago when the project was six months into planning and long delayed due to repeated revisions to the three hundred page functional spec matrixed across sixteen documents. [For the record, that was hyperbole.] Now, having said all that, there are things that can be decent specs, and lots of things that can help waay better than functional specs in establishing a shared understanding. Some examples are stories, scenarios, sketches, and more or less functional prototypes. The stories and scenarios are a much better source for QA and usability testing to start from than a functional spec, and they can feed into other disciplines related to full product creation. Don't do a whole lot of specking--just enough to get folks pointed in the right direction and working within a holistic interaction design framework. Specking should be looked at as a necessary evil that should be minimized when possible in favor of iterative collaboration over a designed solution. -a ________________________________________________________________ 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
