When you’re in a discussion with Framework fans, here’s some arguments you can use to knock them out (metaphorically).
A lot of developers use frameworks to build their applications. It’s not a bad thing per se.
They give you the privilege of not having to choose. Paradigms, languages, philosophy, style, patterns. Everything is included and fixed already.
Frameworks allow for Rapid Application Development or, how I like to put it, Throwaway Learning Focused Prototype Development (although RAD is definitely a cooler acronym than TLFPD).
But what happens when things get serious? What happens when your project scales in term of codebase, features, standards and people working on it?
The trade-offs you made while building your RAD application will appear in your backlog in all their technical debt glory.
Not only that.
By the moment you adopt a framework, you already delegated to it the most essential decisions about your project:
- quality standards;
- coding style;
- application patterns;
- domain logic shape;
- data representation;
… and so on.
Yes, yes, I know. Good frameworks are fully configurable. But no one is taking care about that at the beginning because that’s the whole point of a framework: you just want to start coding.
And when you want to change your non-decision, it’s already too late.
Frameworks allow for Rapid Application Development or, how I like to put it, Throwaway Learning Focused Prototype Development (although RAD is definitely a cooler acronym than TLFPD).
Among all the arguments for not using a framework, though, there are three that I want to specifically talk about:
- When you go Frameworkless, you’re not reinventing the wheel;
- Frameworks introduce a huge Mess-up Surface;
- The <Framework> Software Developer nonsense must end.
These three points are so important that, as you may imagine, are usually ignored in the average framework yes framework no discussion.
When you go Frameworkless, you’re not reinventing the wheel
Going frameworkless doesn’t mean you have to write everything from scratch.
Framework fans tend to forget that there are some nicely packed artifacts called libraries.
And guess what? Their beloved frameworks use them too!
Which wheel are we talking about anyway?
Only you, as the owner of your project, know if you’re building a scooter, a tractor or a sport car.
You deserve the responsibility to choose the wheel that fits your need. And possibly the size, the material of the tire and the quality of the screws as well.
Frameworks introduce a huge Mess-up Surface
I found a formula for explaining that:
Mess-up Chance = (Framework Surface x Team size ) / Enforceable Constraints
The larger the framework surface (namely the number of public components) and the team size and heterogeneity, the bigger the change to entangle your project into the technicalities of your framework.
<sarcasm>
Your project needs an event publisher. The framework has a messaging system. Let’s bend your needs so they fit into the framework features!
Why do you need to evaluate other libraries if the framework already has a component that does something that even remotely resembles what you need?
Why go and buy a corkscrew if you already have a shoe and a wall?
</sarcasm>
Conversely, picking your libraries one by one by evaluating them in the context of your use-case dramatically lowers this possibility.
Also, the introduction of a library is something that is easier to control in a large team. A quick check on your list of dependencies will do.
Try to do that throughout your codebase when anyone can just reference a class and start using it right away.
In other words, frameworks are demanding and highly entropic. Without even noticing, they stop working for you and you start working for them, mainly to avoid that things get out of control.
The <Framework> Software Developer nonsense must end
Ok, seriously.
There’s no glory in identifying yourself as a <Framework> Software Developer.
No pride either.
What will you do in 3–5 years (6 months for Javascript)? Change your job title because the framework went out of fashion and do that over and over?
Sorry, I have very bad news for you.
All the knowledge you are accumulating about the most private, inner part of your framework is going to be useless very soon. You’ll forget it to make space for the next framework.
Do you remember that nice 500$ certification you were so proud of that you hanged it onto the office wall? You’ll eventually throw it in the trash bin.
Recruiting is also a big, big problem in this regard.
I constantly receive offers for positions as Laravel/Angular/React Developer.
What should I answer?
“Sorry, I’m only a developer who understands business and try to solve problems with a more agnostic approach.”
Recruiters (at least many of them) do not understand the difference. They only proxy the request of their clients.
Please let’s stop asking them to hire <Framework> Developers, and if you are one of those, please stop identifying yourself as such.
You’re only wasting your efforts building up knowledge that won’t be useful in the long term.
Conclusion
If you are a framework fan and you made it to here, congratulations. I was not expecting that.
In your honor, I’ll acknowledge that there are few times when a framework can be preferred over library picking.
But those are the minority.
My personal heuristic is: if a project is not strategically relevant or very simple in scope, a framework may make sense.
For all the rest, just use your true craftsmanship.