When not to use a framework

December 12, 2017

I'm currently working on a project that involves rebuilding a product that was once built by a contractor. I've been looking through this previous codebase and I noticed a few things that got me scratching my head. I couldn't quite squeeze my thoughts into 140 240 characters, so this was a better space.

There are some obvious issues with this scenario. The first being, how the contractor built this product without my client being fully aware of code quality.

The codebase I was looking through was using a framework, Laravel. What I noticed though is that the developers barely used any of Laravel's out-of-box tools and helpers. The developers went out of their way to engineer their own framework within a framework. Framework inception!

Don't do this! Framework inception is bad, m'kay?

I've also worked on projects that had their own custom framework. It was more of a bunch of vanilla code that loosely matched the companies code style. Things like data models, logging and API methods.

I can only imagine the headaches these developers had. Every step of the way they were up against how Laravel was suppose to work. No Eloquent models were used correctly, no database migrations ran, nothing. It was vanilla PHP fighting against the request stack, middleware, and the built in ORM.

This is a perfect scenario of when not to use a framework. This company should have built their own custom framework. In this case, they really already did. For them, working with a framework was quite simply swimming upstream in a swimming race.

Know your tools and more importantly, know when to use them.

A layman's explanation of a development framework

Building a product with a framework is like building a Lego car with a box set vs building with spare Lego you have laying around the house. Everything you need to build a car comes in that set, almost. If you want fancy wheels, you can get a separate Lego set with fancy wheels and add those on.