William "Chops" Westfield wrote:
> (I hardly ever do functional or design specs for "personal" project,
> although it seems like it would be a good idea.  If I'm lucky,
> something similar might get written up AFTER the coding, as a sort of
> step toward publication...  Sigh, again.)

You're not alone. If you're the developer and the customer at the same time, 
I think this approach makes perfect sense.

I like the Agile approach: whip something up very quickly, see how you like 
it, make a change, see how you like the result, repeat. Rigid specs based on 
incomplete information, are counter-productive.

Even if you have a customer, same idea works just as well: whip up a quick 
prototype, get customer's feedback, make the changes, another review...

One of my professors described what happened in the days before Agile: he 
worked on a project team that was in charge of developing some sort of 
meter. Based on prior experience, the most frustrating part was getting the 
interface "right" (as defined by marketing folks and other non-engineers). 
So, one of the guys on their team put together a crude representation of the 
device interface in VB, which was shown to the marketing department. "Add 
five buttons, put this button in the left corner, make it red". Several 
iterations quickly followed, and eventually, the comments widdled down to 
"change the font color to white", and "make this text lowercase". According 
to the professor, the project was a big success.

We have this sort of informal "customer reviews" for the products we 
develop. Documentation is usually written based on the project artefacts, 
after the main development is done.

Vitaliy


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist