5 Reasons Bad Developers Will Give for Not Using an Application Framework
I know what you are thinking.
In this day and age, who would not want to use a framework?
If you have enough confirmation bias, however, the internet will provide you with evidence.
I have met at least a couple of tech leads who have denied their teams the comfort of using a robust framework. One of them worked at a company that had raised more than $9M in funding rounds — Accel Partners was one of the participants.
Don't make the mistake of thinking that companies that allow their leads to perpetuate such stupidity will quickly get lost in oblivion. Well, they eventually do, but not without burning a lot of their investor's money.
Without further ado, if you are being sold this idea of not using frameworks, here are the top five reasons you will hear and the subtle undertones of incompetence that they carry.
5. Frameworks are complicated
This is one of the favorites. You hear phrases like, "there is too much magic happening in there" or, "setting it up will take a lot of time" or, "it works while it works, when it stops..." etc. This person is evading the responsibility of understanding the framework thoroughly.
The person advocating not to use a framework because it's complicated probably never understood the difference between Complex and Complicated.
Of course frameworks are complex, because they are created to tackle complex problems and reduce the complications that would otherwise result from bad design.
They don't even realize that there is a good chance they will indeed end up with a bad design because only 1 in 50 developers is able to define good abstractions.
In short you are being told, "I can't wrap my head around this complexity yet and I don't think I will ever be able to make this work. So, I'd rather let the junior developers toil away barebones. When they are stuck, it'd be their fault."
Try stating these aphorisms to convince your boss.
- A system should be as simple as possible, but no more.
- Simple is better than complex. Complex is better than complicated.
4. Frameworks inhibit learning
Another gem. A bad tech lead will try to convince you that you need to learn what happens under the hood. They don't know that there is such thing as a good Abstraction.
Their priorities are misaligned because they think that in order to use something, you need to be aware of every implementation detail, regardless of however ingenious or mundane it may be.
They also fail to understand that by reinventing the wheel, they are making a huge dent in their company's finances.
Reinventing the wheel requires lots of resources that cost money — you end up with a buggy, low quality product that costs even more money. They may be suffering from Not Invented Here syndrome.
3. No framework can cater to our special needs
Citing this problem requires a some level of grandiosity and myopia as well. Good frameworks are designed to be as generic as possible.
Not only does it cater to a wide variety of audiences, the makers have probably already figured out your future needs that you yourself might not be aware of.
Because, hey, roughly 90% of software projects have the same horizontal concerns.
A good framework could possibly have a decade of experience coming from a wide variety of contributors belonging to different domains, distilled into code.
It's unlikely that you bumped into a special case that is not already addressed. Even if that happens, most good frameworks will allow you to extend their functionality to custom fit your special requirement.
2. Using this framework will require me to use X
Good frameworks allow you to use as much of it as you want and don't get in the way when you don't want to use its features.
Take, for example, Spring for Java and Symfony for PHP. You can use any of the features provided by these frameworks independently, for example: Routing, ORM, Dependency Injection, or Security, and use something entirely different for other stuff.
People holding this opinion do not peruse the documents — they just skim through it and assume that whatever they read under the same domain name is the lowest denominator and cannot be broken down further.
1. Performance
And the top spot goes to... "Using frameworks results in bad performance." If only I had a dollar for every time someone blamed the framework for their incompetence.
Frameworks, ideas, dependency injection, and annotations get rejected because of non-existent performance issues. People often cite this reason when all other reasons fail. This one is a very good conversation finisher.
Since you've never used a framework, you couldn't possibly know what effects it will have on performance. Even if someone says this from personal experience, I am unlikely to believe them.
Chances are, no one tried to figure out the bottleneck. Since frameworks can't advocate for themselves, they became a convenient scapegoat.
Performance overhead caused by good quality frameworks is only ever an issue when memory is at a premium, for example, in embedded systems. Modern day computers (including cellphones and servers) provide copious amounts of RAM at a very cheap price.
Whenever someone tells you that using frameworks on web/mobile/desktop application causes performance issues, ask them for benchmarks.
If the person has really taken time to locate the bottleneck, they would love to fire up a quick benchmark and claim bragging rights for taking down that famous framework.
Otherwise, they are living inside a bubble. Do them one better by presenting them with the benchmarks. With good frameworks, performance overhead will be negligible.
On the other hand, the opposite might be true. Custom code might be less performant because a good framework is used by many people with varying needs, thus is audited more frequently and thoroughly.
Conclusion
The idea of not using a framework stems from a superficial analysis or sloth. Do not fall in this trap unless you count yourself in the ranks of Linus Torvalds— in which case, be like Linus.
Lastly, let me end with this quote.
Let "performance reasons" be the last resort of all sleeping [wo]men.
Find more of my writings at http://codinglama.com.
