jeudi 11 novembre 2010

Should your company develop it's own framework ?

Having had some discussions with colleagues about building a framework, I just wanted to share my point of view, hoping it may profit to someone.

Adapted to your needs

A framework, per definition, is generic. If you develop one yourself and you do it right, your home-made framework will end up having as much abstraction as a public one.
On the other hand, a public framework can be adapted to some specific needs you may have with less effort than developing one from scratch.

What about tests ?

A public framework usually comes with a full stack of unit tests. And every modification or addition to the code will have it's accompanying tests.
It will take you a good deal of time and consistency to accompany each and every change to your home-made framework with it's unit tests.


You're developing a framework for your company so everyone can take benefit of it. So you have to document it properly. Not just API documentation, but also a developer reference guide so anyone new to the company and the framework can get up to par swiftly. That requires time too. Writing documentation is not that easy as you might think it is, either.
Public frameworks -at least the major ones- come fully documented and the documentation is being kept up-to-date as the framework evolves.


The framework you're developing will be used by not that many people (unless you release it out in the open and it becomes a success, but then I guess it'll have no specificities to your company any more) and security flaws and bugs will not be detected rapidly.
Public frameworks are being used in many applications. So security is one of the major concerns of the contributors of a public framework. Besides that, many people using the framework in many different ways, bugs are rapidly detected - and corrected.


By it's nature, the proprietary framework will have a far less big user base than a public one. So support for it is naturally reduced to a few people, if it is not just one person.
I'm quite sure you'll often get a response to a question more rapidly and accurately from the user community of a public framework than you will from the gurus who wrote the one for your company.


Last but not least, it'll be easier to recruit if you're using a public framework: it's quite obvious no one will know yours!


In the end, and in almost any case, there's no valid reason for your company to develop it's own framework: it'll cost more time & effort than adapting an existing one, and that includes performance optimization if needs be.
As a side note though, I'd encourage any developer to try and build his own framework or actively contribute to an existing one. You learn a lot from it!

1 commentaire:

Alexandre Altun a dit…

Thanks for the post, there are lots of truths in it. However, it would have been interesting to write about the benefits of an home made framework.

I'll try to do it here.

Adapted to your needs
Yes, a framework is generic. But what make you choose, let's say, Zend over Symfony? I guess it's because you find it more adapted to your needs (because you don't need any ORM or whatever). So IMO, even being generic, an home made framework can be more adapted to the needs of the project.

What about tests?
If I understand you right, you say that tests help you to modify the framework. I agree but if you start to write you own code in the framework, you will have a hard time updating it, and it can be annoying if the latest release intend to fix a major security issue that impact you! I'm not saying that tests are useless but they're not such a big deal when you're using a public framework that you won't modify.
Moreover, tests for the critical components of a framework can be written in a reasonable amount of time so you can quickly get up to par with public frameworks.

You have a point here. Documentation takes time and there's no way to fight with the documentation of public fw. However, if you're code is clear enough, as opposed as Zend's mess, you won't need 3,000 pages for the user guide and you won't need tousands dollars training sessions.

Security is a double-edged sword. If you choose to use a public framework, yes, there will be less bugs and less security issues. But in the other hand, if a break is discovered, your project will be impacted and everybody will know about it.
With a proprietary framework, you won't have this problem and common security issues can be taken care of easily. Even if you let a critical bug in your framework, nobody will hear of it... You'll have plenty of time to fix it.

With the time passing, more and more developers will be able to help new recruits to adapt to the framework. You can even imagine to have an internal Q&A forum for technical problems. This way, the gap with public frameworks will tighten every day.

I'll let you conclude. ;)