NYCPHP Meetup

[Patrick Ramsden]

> I want to share with you what I have learned through
> my actual work experience, I hope you'll find it
> useful.  Planning a large system should start out by a
> process, referred to as (1) requirement gathering and
> (2) specification writing. 
> 
> Before you write even a single piece of code you
> should decide what you want the system do and how,
> thoroughly and in detail.  You'll know you've done
> this part right when you can describe the system in
> detail and complete with all the user interfaces,
> again before you start coding.  When you're writing up
> your specification, based on the requirements, your
> technical choices should address not only providing
> for the requirements of the system today but also some
> future extendibility.  For example should you require
> the users login to the system?  How should you
> validate the information and what should be done if
> the validation goes through or does not go through. 
> If you have a set of information or options that are
> valid today would they always remain the same or would
> you like them to change sometime in the future?
> 
> The process is almost intuitive once you develop the
> right mindset.  I hope this helped.

Great thoughts.  My two cents:

I agree wholeheartedly that it's important to elicit business requirements
for what you're developing and to consider expected/potential changes that
could be required in the future when architecting a system.

I'd suggest being careful of too much "big design up front" (i.e., spending
a lot of time on architecture, especially of things that aren't immediately
required).  Usually the best approach is to try to iterate as much as
possible -- i.e., flesh out some requirements from the "customers" (usually
the business folks), develop and test the functionality that's most
important to them (not the nice-to-haves) in a short timeframe (e.g., 1-4
weeks), and then give it to them so they can use it and refine their
requirements (which usually leads to the software providing more value for
the business).

Extreme Programming, one of the agile development philosophies, stresses
trying to do the simplest thing possible when developing a feature.  Usually
the cost of refactoring something that could be architected better is less
than the cost of developing features that aren't valued or used...

-Pat