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.