NYCPHP Meetup

[Phil Duffy]

> -----Original Message-----
> From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org]
> On Behalf Of inforequest
> Sent: Friday, September 16, 2005 12:14 PM
> To: talk at lists.nyphp.org
> Subject: Re: [nycphp-talk] Code cleanliness vs. code popularity

John Andrews wrote:

> There is alot of cognitive overhead to classes and frameworks. If you
> have to step into an app, you need to get to a point where you can
> visualize the framework before you can be sure of the consequences of
> changes, right? That's a big headache for a highly-utilized yet
> infrequently-modified system.
> 
> With procedural code, a new coder can step through it rather easily and
> be pretty sure of the consequences of change... the places where scope
> is ill-defined or dependencies exists pop out at you.

Hi John,

I think you have hit the nail on the head.  I am going through the process
of learning PHP, XHTML and CSS while developing a major application that
uses PEAR libraries and an MVC framework.  I have lots of procedural
programming experience and lots of object-oriented design experience, but
little object-oriented programming experience (a strange combination).  The
learning curve is steep because things are not always done the direct and
obvious way, but in a manner reflecting "best practices".

I believe we are dealing with a tradeoff versus an absolute on this
question.  For a "highly utilized, yet infrequently modified system"
procedural code may be the right strategy.  However, I can't recall too many
situations in my career when I was exposed to that kind of project.  Clients
seem to want to extend successful systems and you reach the tipping point
where procedural code maintenance becomes increasingly problematic.  It is
difficult at that point to reverse field.

It is too soon to determine if my current project will be a success, but
currently I am pursuing a modification of your rule - if there is any doubt
about extending the system, accept the grief of the steeper object-oriented
learning curve and framework and simply accept this as a cost of doing
business.

I hope this perspective helps.  Clearly we are dealing with a subject that
lacks absolutes.

Phil