On Nov 19, 2007 7:05 AM, David Krings <[EMAIL PROTECTED]> wrote: > Urb LeJeune wrote: > > It all depends upon you philosophy of programming. To most > > people a good program is one that works. To me a good program > > has three important characteristics: > > > > 1. It does what the specifications require under all circumstances. > > Number 1 is a tricky one. You are saying that your program is a "good program" > even when it does exactly what the crappy and misguided specs demand?
Yes. Absolutely. The program must do what the spec defines. The two must match. This encourages re-usability later on and prevents scope/feature creep up front. Plus, your docs for the code will come from the spec and can be completed in parallel. > The > simple requirement of "program that works" may be closer to the anticipated > goal than one that follows the specs to the t. Good specs are hard to come by > and writing good specs ina pain the behind. True, but I believe this problem to be due to not having the right people not involved in the spec. In my experience, especially on small teams, the engineer is writing the spec, with limited feedback from the stakeholders. The engineer would rather be doing something creative or writing code, not hashing out the details of this document. So, new features and "hey, look, this would be better..." gets added and the project grows. Then, the spec is never updated and the next folks to pick up the project don't have a reliable spec. Plus, deadlines do eventually set in and cool-feature-Y that wasn't in the spec is now hacked in to meet it, so it isn't re-usable as everyone had expected. If you're working in a small client/consultant relationship, there probably isn't a PM or a Product Mgr, so the engineer will probably end up writing the spec by themselves. In which case, you need to have the client sign off so everyone agrees what should be there up front. No one says you can't change the spec mid-course, but you have to actually update the spec and documentation to reflect this change. Tom LIPHP _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
