In such a rapidly evolving tech world, it’s easy to notice how frequent the use of frameworks, libraries and tools has become. From data management and database friendly layers, bitmap pooling and caching, networking abstraction layers and all the way to reactive frameworks, these tools are everywhere, available to us. And to be honest, the credit is rightly theirs.
We no longer need to start everything from scratch. We no longer need to reinvent the dreaded “wheel”. We no longer need to to concern about those nitty-gritty details of how some pieces of software are really working. Why even waste the time in writing code that has been written so many times and which also takes so much space?
We just plug in an appropriate library and voilà!
We now get a nicer cleaner code. It’s much easier to read and all those lengthy classes and all of that code are gone. These were, after all, some trivial tasks. Now there’s more time to invest in those really important tasks.
Does this sound familiar? We all did it. And we might be still doing it.We usually go ahead and start stuffing a project with so many frameworks that it can barely withstand the stress.
What stress?
The stress of change or the stress of extinction. If the frameworks that you have tied up to your project have started rapidly changing, you might find yourself updating the project constantly. Sigh..
Or even worse, those tools might become deprecated maybe even gone. Like Parse. So you frenetically start looking for another “reliable” tool.
And so, you become addicted to tools and start integrating as many as you can into your project. This is like a new sensation, a pressure constantly pushing you to become dependent.
Dependent to what?
I never thought of anything negative at that point. I was really hyped ’cause I got more time and everything looked easier and cleaner now.
And what pressure?
In the constant adventure of being a developer, one has to learn all the time. What happens if you sit back and relax a little bit? You usually fall behind so bad that you need to start a learning process because there are so many new technologies and tools out there, unknown to you. In the blink of an eye, right?
You really want to stay on top and be able to use them all.
That’s how the addiction kicks in and why tools start pressuring you.
Companies love that. In fact, they would rather hire somebody that can use a couple of new tools than getting a skilled developer that unfortunately hasn’t used FireStamper (don’t worry, there’s no such tool). There’s something really wrong here. Companies should never judge one’s skills just by his capability of using all the frameworks and tools ever invented and even the ones that haven’t been. Yet that’s a long long topic for maybe another day.
So you start learning. And usually when learning something new, you want to get a hard grasp on what is really going on. In my case, alternating from Android development to iOS basically meant having a rigorous learning programme. This included reiterating networking, data persistence etc. — but this time on iOS.
And that’s when it struck me!
I haven’t written code like this for ages. Not using any framework or any tools instantly made me believe that my code was much powerful. And I didn’t have to worry about choosing any tool, or any affected dependencies or changes etc.
What actually happens when we start becoming tools addicts is that we no longer have that edge. We are no longer required to write “that code” so we never think of it.
Does that mean that we get soft?
It might not mean that. But what for sure means is that you have now delivered a product with tons of dependencies. Which means that if one of those dependencies might fail, so will your product. Who wants that? I bet your product manager doesn’t.
Now maybe you have heard of that. But what if you get into a company in which the product manager tells you this:
“In delivering the product, you are not allowed to use any libraries, frameworks or any other helping tools.”
Now this is might sound crazy and highly unlikely, maybe even undesirable. Yet, what would we do? We would probably realize how dependent we have become.
And come to think of it, having no external dependencies would mean the whole development team would have a common language. Nobody would worry getting into a project that uses weird looking code because of a new framework.
But, tools are great, right? And those frameworks really help us, don’t they?
They do. And nobody contests that.
For Android lovers, can someone recall bitmap handling before Picasso, or Glide etc? Can someone recall the pain of Async Taks management before RxJava came along?
The truth is that these tools do help us.
Anyone can agree on that. We stop wasting so much time doing repetitive coding tasks that don’t really present any difficulty whatsoever. And even if they did, we would be able to have the product ready for deployment much faster, right?
Some might argue that it’s better to deliver a product dependent on a framework than not deliver the product at all, or deliver it late. Which is true, but is it really a good long term solution?
What do you think is better? Is it better to continue using tools or is it better to start freeing yourselves from these addictions?
Turn this into a discussion. Throw your two cents in the comments. Also, I really recommend a read up for those interested. Check out Uncle’s Bob article on how the new rising tools might just be reiterations of old tools/technologies.
My answer on this matter lies below.
If you haven’t rushed to conclusions, you might have noticed that as in any complicate matter, there is no right and wrong answer here.
The solution lies in our ability of deciding which tool we really need. And in which framework we are confident enough that they are mature and would bring enough value to tie it to our project. When building scalable products, remember that it also has to outlive the application.
That’s why balance is desired.
I would personally try to restrict the usage of 3rd party components to the minimum. But not entirely.
If you’re learning though and building side-projects, I would encourage using any tools/frameworks that can boost your ability of working with high-level modules. After you feel confident enough, you can start removing these abstract layers and build the feature without involving any helping tools.
Thanks for sticking out with me to the end. Don’t forget to share your thoughts on this topic in the comments.
Remember, if you liked this post subscribe for more by using the bottom subscribe widget! And if you really enjoyed it, then you can buy me a coffee here! Thanks!