Re: [UG-ADMINS] Project Planning

On Sep 24, 2008, at 1:29 PM, Hans Zaunere wrote:

> Hi Tim,
>
> I don't have many answers, but here is some food for thought:
>
> -- there is no one no good way, so it's really about flexibility in  
> a project

Precisely.  I'd like a discussion of some different approaches, but  
mostly, I'd like to take developers open their normal tight mental  
focus and consider architectural solutions to enable such flexibility  
prior to coding.  Thinking their way all the way around a project  
rather than aiming at the primary goal and treating all the  
subsequent complexities that follow as patches or fixes.

> -- business people don't get development, so flexibility is even  
> more important

Businesses don't understand development, but they DO understand  
modular construction, which is where more and more PHP development is  
headed (especially since frameworks started becoming more important  
and widespread).  Unfortunately a lot of traditionally procedural PHP  
developers don't think in terms of breaking diverse problems into  
separate code sets that work together but don't necessarily rely upon  
each other to function.  In some regards, the challenge is conveying  
the basics of OOP, but mostly it's demonstrating how to avoid  
spaghetti code through good planning.

> -- that said, there are some generally accepted best practices that  
> will not be contentious amongst developers, project managers, etc.
>
> -- The fundamental concepts are important to discuss - I'd start a  
> discussion on the mailing list, have someone organize and record  
> the various comments, and then put together bullet points outlining  
> the fundamental topics/concepts
>
> -- present this to the list, ask for speakers, and perhaps have a  
> panel style discussion at the meeting
>
> -- put resources online for future reference.  this is akin to our  
> PHundamentals which was hugely successful, although getting a bit  
> dated because of lack of time


At the moment, we don't run an interactive mailing list.   
Participation on our lists and forums has always been moderate among  
students and hobbyists but really low on people who actually code  
full-time.  (They don't need to participate just to find answers, and  
they appear to get frustrated at checking in once in a blue moon to  
find bad advice and too many misconceptions to even try to correct.)   
This absence of the experienced often creates an environment of the  
partially sighted leading the blind - which isn't entirely useless,  
but it's more successful and more rewarding when the experienced and  
inexperienced meet face-to-face.

> And from my personal experience:
>
> -- only large, rich corporations have the resources to dedicate the  
> right amount of time to discovery and specification - and even then  
> sometimes they don't want to
>
> -- most gigs are about agility; even if the business person says he  
> knows what he wants, he doesn't.  So be clear with him that it's  
> going to be an iterative development cycle, with give and take on  
> both sides

Yep.  Which is why I don't want to preach any particular development  
process.  I want to discuss what issues a dev should consider, and  
how to keep those issues from being afterthoughts.  I want to discuss  
various concrete examples of how planning the architecture can  
complicate the coding, but why it's often worth building in that  
complexity (enabling later expansion, maintainability, monitoring,  
caches and performance tweaks), and how to be able to explain that  
worth to their employer without sounding like a con-artist.

> -- what this really means:  always do a day or hourly rate - never  
> a fixed bid :)

Absolutely!  We are training professionals, after all.

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




>> -----Original Message-----
>> From: Tim Stiles [mailto:[email protected]]
>> Sent: Wednesday, September 24, 2008 12:09 AM
>> To: [email protected]
>> Subject: [UG-ADMINS] 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
>>
>>
>>
>>
>> --
>> Usergroup Coordination Mailing List (http://ug.php.net)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>