Coding Lama

I know what you are thinking, in this day and age who would not want to use a framework. But if you have enough confirmation bias internet will provide you with evidence. I have met at least a couple of tech leads which denied their teams the comfort of using a robust framework. One of them worked at a company which had raised more than $9M in funding rounds in which 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 into 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 framework here are the top 5 reasons that you will hear and the subtle undertones of incompetence that they carry.

5. Frameworks are complicated

This is one of the favourites. You would 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 to understanding the framework thoroughly.

The person advocating to not use a framework because its complicated probably never understood difference between Complex and Complicated. Of course frameworks are complex, because they are created to tackle complex problems and reduce the complications which would otherwise result from bad design. They don’t even realise that their 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.

1. A system should be as simple as possible, but no more🔗.
2. 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 never knew that there is such thing as a good Abstraction. Their priorities are misaligned coz they think that in order to use something, you need to be aware of each and 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 on their company’s finances because reinventing the wheel requires lots of resources which cost money and you end up with a buggy, low quality product which 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 it caters to a wide variety of audience, the makers have probably already figured out your future needs that you yourself might not be aware of. Because hey, roughly 90% of the software projects have 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 which 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 doesn’t come 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, or ORM, or 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 got a dollar every time someone blamed the framework for their incompetence. Frameworks, ideas, dependency injection, annotations get rejected because of non-existent performance issues. People often cite this reason when all other of their reasons fail. This one is a very good conversation finisher.

Since your 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 and 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. Or do them one better by presenting them with the benchmarks. With good frameworks, performance overhead will be negligible.

On the other hand, opposite might be true. Custom code might be less performant since 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.