We love building custom software our way, but there are dangers along the way!
I think building a framework is a supurb way to improve in any programming language. There is no better way to learn than by trial and error. I also think it’s best done when you follows a proven design pattern, but not everything should be the MVC buzzword of the last few years. I’m not in any way opposed to innovation or new frameworks, but I think we should tread with caution.
A framework has one purpose: To make someones job easier.
Increased Development Time
Developing a framework is a large time dedication. Frameworks go through beta’s, release candidates, new versions and even self promotion. A developers task to manage versions and backwards compatibility at times would also get quite annoying. I often prefer libraries for custom solutions rather than frameworks, it’s easier to manage.
One Size Fits All
A grave danger is the anti-pattern of The Golden Bullet: Assuming that a favorite solution is universally applicable. Not every project should be an MVC based project, nor should every project be a custom rolled solution.
The trick is to find the right tool for the task. Although I love CodeIgniter, sometimes it’s not the right tool. For a very simple one page site, why do I need a full MVC framework? I don’t at all, it could be a few PHP pages.
Another example, if I had to fetch 200k queries for a file output the CodeIgniter Active Record will hog resources and cause PHP to die from exhausted memory. A workaround is to prevent caching of the AR Class or do a raw query. Even when it comes to database wrappers not everything may be suited for an ORM or Active Record and vise versa.
If you want to get bit in the butt then use a custom framework with your team! This can be trouble because nobody will know it better than the author. This will cost your team time to adapt to a new methodology, and potential problems that halt development when you are on vacation.
If you bring in a new person to the team, they are more likely to know a popular open source framework than one privatized. This is why I suggest if you use a custom framework that it follows some design pattern principals so the learning curve would be less steep. As well as ridiculously good documentation which I bring up in the next point.
Recently, I had to look back at a custom PDO wrapper I wrote about 2 years ago and I had a bit of trouble remembering how it worked off the top of my head. That was only one file, I can’t imagine going back to a framework I built with 50 files that could be four versions behind!
Any framework/library must have documentation and examples. If it doesn’t then you are headed for cheese right under a mouse trap! When I saw the Zend Framework 2 documentation when it was just released I left it behind because it was terrible and cluttered. Almost non-existant. I haven’t bothered coming back to look at it.
Frameworks are meant to make our lives easier, not harder. I want to be able to take a framework and start using it after seeing a few examples. When a framework is written it’s understood best by the developer, but his or her job is now to present it as if they have no idea how it works. Then the rest of us bimbo’s can understand. Good documentation is ridiculously important.
Keep on Developing!
If you choose to continue developing a framework don’t let me stop you. These are great suggestions to keep in mind. You will have a big task and a lot of people will depend on you if you gain popularity. I personally do not find is as satisfying as turning out projects, but to each his own.