php[architect] logo

Want to check out an issue? Sign up to receive a special offer.

Arrogance is Limiting Framework Adoption

Posted by on June 15, 2009

 “…Frameworks! I don’t need no stickin’ PHP Frameworks!!!” – anonymous twitterer

The arrogance embodied in the sentiment form the above tweet is amusing. It conjures up memories of young programmers thinking they can own the world. Some of them can, no doubt. However, if your goal is to build systems for customers or your company, you will need a framework. The truth of the matter is, to build modern systems, you do need a framework. What I really think what the tweeter was trying to say is:  

“…Frameworks, I don’t understand no stinkin frameworks.”  

Modern-day PHP frameworks are huge beasts. The top-tier frameworks have procedures in place to make sure that not only every line of code is vetted but every idea entering the framework passes a rigorous inspection. Once the concept has been approved, though, the code is designed and coded by a single developer or a very small team. What sets these developers apart is that they are “subject matter experts.” They understand their piece of the puzzle intimately. They have thought it through, hashed it out and defended their design publically in order to get their solution
accepted by the community at large.    

It is because of these small teams of one or more that modern frameworks can be complex while still being useful. If one developer attempts to write a framework by him/her self, the result is not as good because one developer cannot be an expert in all the problem spaces that have to be solved.  Quite simply put, “all of us are smarter than one of us.” Or, as James Surowiecki, author of The Wisdom of Crowds put it: 


“The wisdom of crowds comes not from the consensus decision of the group, but from the aggregation of the ideas/thoughts/decisions of each individual in the group.”


More important than the size of the framework though is the fact that they are designed to solve complex problems. If you are trying to build your own blog, give up and install WordPress, save your energy for problems that can’t easily be solved.  

If you do your homework and find a framework you can trust, then you don’t have to solve problems that others have already solved: you have the building blocks for complex systems at your fingertips.

The problem is, like the tweet above points out, that many developers are arrogant. They don’t believe in the Wisdom of the crowds or the Wisdom of the community, they believe in their own code.

By adopting one of the top-tier PHP frameworks and spending the time to climb the learning curve, you can spend more time doing what you do best, solving problems for clients. You can write the 20% of the code that makes your client’s applications special instead of the 80% that is common across all applications.  It’s rare that a client will pay you to build a better mail client; they want just want you to help them communicate better with their customers.

Frameworks have come a long way and, if you have not mastered one yet, you may find yourself lagging behind your peers. In any job market, that’s not a good thing—but, in a difficult market, that can make the difference between employment and unemployment.

Pick a framework that has a thriving community and then spend the time to learn it. Quit re-inventing the wheel, start using the wheel to solve your client’s problems. Get out there and build them a car.


Cal Evans is a veteran of the browser wars. (BW-I, the big one) He has been programming for more years than he likes to remember but for the past [redacted] years he's been working strictly with PHP, MySQL and their friends. Cal regularly speaks at PHP users groups and conferences, writes articles and wanders the net looking for trouble to cause. He blogs on an "as he feels like it" basis at Postcards from my life.
Tags: ,

Responses and Pingbacks

While I’m sure that arrogance does come into it, to my mind the three main barriers preventing developers adopting framework use are complacency (taking the effort to learn a framework when arguably you can achieve the same goals with what you already know, regardless of the above arguments), letting go of a certain amount of control by relying on someone else’s code (and opening yourself up to framework-targeted attacks) and risking the scalability of your projects. You’re not going to be impressed, having selected a particular framework and invested your time in it, to find that in three years the industry has gone in a different direction.

When I was taking the transition from junior to mid-level developer we were working with Mojavi. The lead developer had messed around in the core and us minions were writing various modules for the specific application we were developing. This showed me where a framework gets used.

As a learning exercise I tried to write a small ‘framework’ for myself, to mimic how our existing framework was working. It was a good exercise and I learned a lot from it.

Since moving on from that company and transitioning again, this time to a lead/senior developer I keep coming back to frameworks and there’s a common problem – they’re just not flexible enough.

So far, I’ve chosen not to adopt a top-tier framework die to the learning curve, loss of control, ease of fixing/debugging and lack of flexibility.

At first, it wasn’t so much arrogance – it was more like “I want to learn how to do that too” (so selfishness, then?). Now I see where they are needed, but at present don’t feel I’m in the same place

Chris, I hear you. And, after working with over a dozen frameworks, I’ve come to the conclusion that being a “top tier” framework owes at least as much to marketing, user management complacency and “job security through empire building” as to real technical merit. Once you get far enough down the road of a particular “leading,” deceptively-megalithic framework, it’s hard to walk away from the sunk costs. That worked for Microsoft in the Windows era; it’s working for at least one major PHP vendor now — even with a far more fragmented market, with “none of the above” holding a very respectable share.

I have three or four frameworks that I select from based on the needs of the project. My defaults are Kohana 2 (for MVC) or Kohana 3 (for HMVC); the differing architectures mean that if you’ve learned one, it’s easy to get complacent enough to dig yourself a really deep hole with the other. But each has its uses.

The last time I was asked to put together a team with a set number of people certified with The Big Framework, I asked the client which he’d rather get done in the same amount of time: building a team with the specified size and paperwork, or getting the project done with two people using a toolset that any competent PHP developer could walk in and pick up. Fortunately, after a week of indecision, we started implementing the second alternative. It’s been in production for several months now, with two major feature enhancements and no “ZOMG! WTF is this?!?” experiences.

And, to me at least, that’s one of the major (mostly unfulfilled) promises made by any framework; it operates in a way that is consistent and predictable enough to just “fall off” your mental radar, so you can concentrate on how to get the job done… instead of how to wrestle “the system” to get the job done.

Leave a comment

Use the form below to leave a comment: