NYCPHP Meetup

[Tom Melendez]

On Nov 19, 2007 7:05 AM, David Krings <ramons at gmx.net> 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