I'm with Susan on this. My job as a consultant is to help clients define what they want so that anyone can code it. My job as a programmer is to implement the spec that was defined. These are two separate skills. Without specs the programmer codes what he/she thinks is required, leaving the client later to ask "why isn't 'this' in there", or "why did you do 'that'?" A spec helps to eliminate the questions, to make sure things aren't forgotten, and to prevent rifts between client expectations and contractor delivery.
It's certainly true that people can take specs to extremes, with four hours spent on specs and one on code. But there have been times when some number of hours spent on a spec revealed that there wasn't enough information to begin coding, or that the project was much more extensive than imagined, so no programming was done at all. Compare this to situations where weeks or months of coding is done and then trashed because someone down the line realized the code wasn't necessary, or that it all needed to be re-written because it didn't agree with existing policies. Getting the job done isn't just about creating functional code, it's should include making sure that the next person in line understands both what the code does and why it does it. Creating a proper balance between spec time and coding time is yet another skill that people should develop over time - and this is what helps to separate professionals from amateurs. Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com NEW: Follow TonyGravagno on Twitter remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
