Project Planning

A year ago we held a session on teamwork tools, communication methods  
to use when either working in a team multiple developers (something  
fairly rare among most local PHP devs, who have been historically  
freelancers), or tools that can be used to keep track of goals and  
progress when your project is too large to keep entirely in hour head  
at one time (inspired by a blog post from Paul Graham).  We discussed  
outliners, UML tools, some great document editors, work ticketing and  
production tools.  We also regularly bring up version control and  
working in dedicated development environments.

What I really wanted to get into was to get into the actual planning  
of large applications, but with so many different schools of thought  
about how much planning to do before you code (and never really  
having had the luxury of enough time to do as much planning as I've  
wanted to), I wasn't sure how to structure it.  What I didn't want  
was "Here's a problem and here's how I solved it".  I want an honest  
to goodness discussion on planning large projects, because we have  
some extremely smart guys in the group and there are many things at  
which I suck, whereas they are very good at them.  No one has the  
time for a user-group open source project, but I think we could get a  
pretty good planning discussion crammed into available time, and I  
want to know what our members worry about before they start coding.

We've had a couple of discussions on frameworks/MVC since then which  
might make a planning discussion easier, but it could limit the  
discussion at the same time (and while the discussions of frameworks  
are always civil, there are aspects of holy wars to them which could  
flare up once you get off of  theory and start talking actual  
implementation)

I've been thinking about simply showing up and asking the room "So,  
how would you define, plan and construct software to operate, say, a  
multi-person blog?" and try to point out specific architectural,  
performance and scale concerns as they come up.  Barely even try to  
control the direction.  Record the all the ideas on a virtual  
whiteboard/outliner, maybe even a local wiki, if possible, so that  
anyone with a notebook can jump in to help.

Do you think we could get far enough into such a discussion to be  
worthwhile?  To reach a reasonable stopping point?  Do you have any  
other ideas or suggestions of how to tackle large issues like  
architecture and planning concerns without overly relying on a  
specific school of thought or programming theory?

Tim Stiles,
Co-Organizer, DallasPHP
WatchMaker, Icomex.com