Revisiting: Why Every Developer Should Write Their Own Framework

In November of 2009, I wrote about why developers should write their own frameworks. I pointed out at the time that often developing a framework forces developers to make the kinds of architectural choices that frameworks require, which helps them better understand the architectural choices in the most popular frameworks.

I haven’t stopped believing in the power of doing as a learning tool. But in the past few months I’ve had an opportunity to move into more of an understanding of frameworks like Zend Framework, and I’ve come to another realization:

The people who write frameworks together are very smart.

I’ve always known that a group of very committed people could be much more effective at producing a good product than I could be on my own, and for a simple reason: the collective mind usually irons out ideas that work much more quickly than a solitary developer or thinker. This isn’t always true, but for the most part, when developers take a look at something like Zend Framework, it should be obvious that the community around it came up with some very good ideas.

Having written a framework and then used an existing framework was very eye opening to me, both in terms of understanding the challenges that Zend Framework must overcome, and understanding how I resolved some of those challenges. There’s also vindication in my approach to some degree: the idea of a front controller that dispatches an action controller is something I implemented in my framework. My implementation is crude, but there none-the-less.

The point of this article is to encourage developers to experiment, but remind them that at the same time, there are already existing solutions that work exceptionally well for many if not most needs. Exploring the concept of developing a framework helped me to better understand the work I was doing; I’m still continuing work on my own framework to this day, not because I use it in production but because it’s something fun and different to work on, and because as I learn new things it’s nice to implement them. In fact, now that my server has moved over to PHP 5.3, I’ll be implementing namespaces next.

Remember that being a developer is a creative role. Remember to dream, to experiment, and then to come back down to earth and use what works best. Development is about invention. Development is about improving things. It’s about never-ending curiosity and always striving to make things better. And that’s why developers should write their own frameworks: because its what we love to do.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

K_Wasseem__7php.com (@7php) wrote at 5/24/2010 8:15 am:

Based on your title, it is understood that you are saying every developer should write their own framework when working on a project.
This is wrong for so many reason, to name some: time constraints, possible bug within the core framework itself..etc

Now, it would make more sense to say (I think that’s what you did explained in the 5th para) every developer should at least try to write their own framework, for it’s a great learning experience.

Else, I really enjoyed your last para, that was nicely done, specially the sentence “Remember to dream, to experiment, and then to come back down to earth and use what works best. Development is about invention.”

Best regards,
//K_Wasseem

Padraic Brady (@padraicb) wrote at 5/24/2010 10:02 am:

It’s really sound advice, there’s very little to match actually doing something (though you should read up first ;)). It’s challenging, forces you to think creatively and gets you into the mindset of solving problems and “seeing the big picture” of an overall architecture.

Kae Verens wrote at 5/24/2010 1:25 pm:

as a person who has written a personal framework and not yet made the switch to a more publically developed one, I must agree.

writing your own framework is very very rewarding, but you’ll miss out on the wisdom of the masses.

i wrote my own simply through evolution – i needed A, which was simple to write, then extended it to also provide B and C.

soon enough, it wad a framework, but with one person that understood it and debugged it.

having other people work on thd framework means that bugs you have not encountered are fixed before you encounter them and features you have not thought of are developed before you realise you need them.

tricky isn’t it… to be a good programmer, it is good to develop your own framework; but to be a good programmer, it is also important to use one developed by a community.

i’m still trying to make the switch to a more well-known framework… maybe i’m just too old? or maybe i just haven’t found the right one for me

Eric wrote at 5/27/2010 11:36 am:

Brandon, I agree with you and think this is very good advice.

Having written a framework with a Data Mapper implementation several years back, I learned the pitfalls of not implementing lazy loading, and how that can kill an application on shared hosting with limited memory. Also, I was able to morph the project from a page controller to a front controller, and learned the advantages of each. Both of these experiences helped me to better understand system performance issues in large applications.

I also think that it is good to work on a well-established framework, or to bring a few knowledgeable folks into your framework development. They can provide insights that will save a lot of time and headache!

Thanks for posting,
– Eric

David wrote at 5/27/2010 1:38 pm:

+1 with me! Framework development is kind of a hobby for me too! And if I must admit that using a public framework is really time saving (because you save on resuse and debugging cost), there is nothing as writing its own framwork to learn a language.

A faced the issue this week, when I tried to figure out whether I should use GET or POST to submit my forms and what was the best way to do it: http://blog.thecodingmachine.com/content/get-or-post-best-practices-choosing-http-method
This was a great learning experience, and I now fully understand the reasons behind the design pattern of many framework (even in ASP.NET!)

Christian Roy wrote at 5/27/2010 9:27 pm:

I wrote my own framework too a while back, for a customer.
Later on, I realized, just like you, how powerful an existing framework is.
My customer’s website still run on my framework, but I would love the opportunity to rework it on symfony or Zend Framework.

It is so true that building my own framework allowed me to understand the inner workings of a framework and become a better developer.

Cheers!

Tim Igoe (@TimIgoe) wrote at 5/29/2010 9:26 am:

I agree, writing your own framework is a very good thing and should be done, at the time I was planning to start using a framework I evaluated a few and looked at my own code base that I had at the time and decided that using that as a basis would allow me to advance my skills, as well as developing something that suited the use I wanted.

The biggest problem I find with more generic frameworks is they are bloated to cover every possible case they are needed for, where as a custom framework can be much more lightweight, and thus quicker to develop with and lighter on server resources.

Where my framework is in use, others work with it too – but I’m the only developer of it, so it does get the extra testing / usage to find bugs which is useful.

ryan (@northxsouth) wrote at 6/6/2010 4:27 pm:

Funny that your thinking on this matter has changed a little :) I happened to come across your original post from Nov 2009 and was trying to figure out how to add a comment. All the other comments agreed with you (same as this post) and I wanted to add a contrasting opinion.

Anyone with php experience that pre-dates PEAR has probably, at one time or another, built their own framework or set of common libraries. Anyone coding under deadline will realize the value of reusable code; it’s just common sense.

But, in the hypothetical situation from your original post on this topic, I would have to side with the boss or community member who is shooting down the new developer who wants to build their own framework.

I’ve designed and worked on php frameworks (from scratch) that ended up being used in production for more than 5 years in BOTH contexts: within a company that had to scale to handle 150k+ regs/day and within a very active, global network of community organizations with significant support needs. (In fairness to me, the projects respectively began in March 2003 and August 2000, so I didn’t even have PEAR available.)

A company or community/nonprofit org should absolutely not decide to write their own php framework in 2010. It’s a software engineering management question without much of a debatable answer. There are just too many rational and experiential reasons that support this conclusion to write them all here.

But, the most compelling reason why an organization shouldn’t waste the time/money to develop their own framework can be distilled into one point: no single organization has the time/money to out-spend the commons/community-at-large (a basic reason why open source code is usually the best option).

For a single organization writing their own framework, the code will improve over time as the dev team optimizes it based on what they learn by watching it perform in different use cases, different load scenarios, different browsers, different server environment conditions, different database sizes (and etc, etc, etc). Also, the dev team’s ability to effectively apply what they learn from each new case is improved as new hires or volunteers contribute their own knowledge/experience to the process.

Now, for a widely-used open source framework, it has already benefited from X times the number of different cases and X times the number of unique developers.

Even if X is just 5 – 10, the value added by the commons outweighs anything a single dev team can do. But, we know that X is much, much higher than 10 for the widely-used php frameworks.

Alright, I don’t want to go on and on. I’m all for developers carefully evaluating not only which framework to use but also whether or not to use a framework. With a nod to Rasmus, high-performing php apps can be built using just php’s modules and PEAR’s repository, coding standards, etc. New developers will learn a lot by studying and hacking on these existing code bases, their revision histories, the different design patterns used, etc.

Copyright © 2023 by Brandon Savage. All rights reserved.