[UPHPU] notes from austin php users group

Joshua Simpson std3rr at gmail.com
Tue Dec 19 11:19:39 MST 2006


On 12/19/06, jtaber <jtaber at johntaber.net> wrote:
>
>
> It's not what PHP needs, it's what companies/developers need.
> Especially in a climate where excellent programmers are few and far
> between.  Thus, good frameworks speed development, ensure standards,
> reduce errors, and reduce maintenance.


I guess it depends on your personal definition of the word 'framework'.  To
me, it's come to symbolize a bloated, overextended set of tools that often
imitates the authors' personal preferred language's (Java, C++, etc) that
often detract usage or hide features of the native language.

Of course, if you mean 'a collection of libraries utilized for one specific
purpose', then I certainly agree.  Of course, extracting and removing
boilerplate code, custom exceptions / error handling, automation, and
sometimes unit testing is par for the course for any good development team.
And, often, internally developed (if done correctly) frameworks will result
in just as much (if not more!) reduced development time, debugging,
maintenance while ensuring standards.  Also, you don't have to deal with
learning Yet Another Framework (tm), which can be just as hard as learning a
new language (and counterintuitive to good said language's developers).



Do you have to have a framework? no.  Can you write your own? yes.  But
> these approaches take time and talent, both of which need to be
> minimized to increase odds of success.


It takes time and talent to learn a foreign, bloated framework, too.  If you
spent your time reusing your own team's 'framework', you 1) grow as
developers in the process, 2) get exactly what you want, 3) and don't have
to rely on an outside team to get what you want.  Of course, you can always
modify the framework to suit your own ideals, but doesn't that defeat the
process?

Still looking for that killer framework - don't see it.
>

If during your development time you slowly developed your own, you probably
would've saved a lot of time spent trying out and learning various
frameworks (and, in the end, be much more satisfied).

dw


More information about the UPHPU mailing list