2018-02-06 14:15:20 | development

Rolling Your Own Framework

As developers, there’s often a temptation to develop everything from scratch. “I don’t need someone else to write a database abstraction layer”. “Saving files is easy, why should I use a framework for that?” And so on.

They’d be correct. These are problems most developers can solve, and given enough of a time investment, their custom code can solve a multitude of problems whilst being robust and comprehensive enough for their needs.

There is a notion then, that developers who use frameworks are “cheating”, or cannot code things themselves. Whilst wrong, the reasons for using frameworks go far beyond the developer’s individual capabilities:

1. The vast user base

A framework, such as Symfony is used worldwide by many tens of thousands of developers across many thousands of use-cases. It is tried and tested throughout the industry by very skilled developers who have every reason to want bugs and security faults patched as quickly as possible. So in theory, if a bug is solved in Doctrine, then the other tens of thousands of developers benefit from this fix.

The same cannot (usually) be said for a custom-rolled library by Joe Developer in his home-crafted framework. It can take months or years for a security flaw to be recognized and then Joe, in this case, has to invest time into fixing this and deploying it to any affected projects.

2. Familiarity

If I need extra staff to work on a project, I can look for a Symfony developer. This person will have had experience with the libraries and knows what to expect from the project so far. I have a good understanding of the code they will produce too, and we should be on the same page. We will both have the same house style defined for us by Symfony.

In Joe’s case, a new developer would need to learn yet another reinvented wheel, which will probably not even be close to the same level of quality as the one which has been through the paces by tens of thousands of developers. The coding styles will be different, as both developers will have their own ideas of where code should be, where curly braces go, and so forth.

3. Support and maintenance

By using a framework, your team theoretically grows by the hundreds. People who are focusing on fixing and maintaining bugs in specific parts of the framework. This then is time which you don’t need to invest. 

They do this for “free” (in that you don’t have to pay them), but again it’s in their interests too. Their projects benefit from it, and so does yours. 

Joe, on the other hand, is one developer who now has to work on a solution which does not break compatibility with all the projects using the same library. Either that, or fix the immediate problem, and hope it doesn't surface on anything currently released...

 

Writing your own framework is good from a learning point of view, and I’m not saying people shouldn’t ever try. Instead, I’ve yet to see a custom-built framework that is suitable for production. I’ve yet to see one which is coherent and predictable - often they end up with a coding style in one section, and a nicer coding style elsewhere - clear signs that the developer is learning, but raises questions admittedly on the stability and maintainability of it.

Frameworks solve the absolute mundane tasks of the project so you can get on with the business logic of the project. Clients are paying you to produce their solution - they are not paying you to spend a week refining the umpteenth-hundred session handler which will probably see three projects in its lifetime at most.

signature