Do you often hear people say: "Back in my days we didn't use these fancy new toys and everything was easier!"? And at the same time some younger developers really like the state of things - the flashy new frameworks, packages and how Node can control everything from a fridge to your destiny nowadays.
Somehow I always hear these whenever we run into an architectural problem. Integration problem. Delivery problem. Ok, ok, a problem. And I strongly believe that all of the things we have and use today aren't either good or bad by themself - it's what we do with them. So here's my short review of what got us here in the first place and what to do now.
Back in the day
It has always been a saying in the dev world: "Reuse what has already been solved." And it used to be done with code snippets, algorithms, ideas. Each solution used to be a custom piece of art, even though we had a standard way of doing things and reusing solutions whenever we saw a pattern. Things were looking good in all areas but manpower. We needed more people, we needed more work, we infiltrated into a million other worlds which were, until then, unaware of what technology can do for them.
And then came frameworks.
Written by developers, for developers, following the same idea. Sounds good, right?
Things became easier to write, easier to produce, publish right away and fire at will! But not without a cost.
Frameworks
Every framework is designed to solve a particular set of problems. You can extend that ability to a number of things other than what it originally was designed to help with, but the framework is still the same. Here comes the problem - the ways.
We're now aware of the React/Redux way, Django way, Spring way, Wordpress way...
Solved and thought about when it was created, there's no need for you to think about a lot of things when using any of these solutions, just stay on the path. But here and there you need a custom behavior, something juuuust a bit different from what the framework offers.
This is where we start to search for compromises.
Is it good to want to stay in the quiet bay of a framework and adapt to a way or should we all create a code equivalent of a Frankenstein's monster? Why not a bit of both, just where we need it?
The Monster
You've done it. You've reached that desired, sweet custom behavior. To do it, you've gone around some advices and listened to some other. It's not exactly best practice, but it's still a good piece of code. A bit here, a bit there and it piles up. Getting new developers on board is harder than ever and customers are pushing to deliver faster and faster.
A new requirement comes in, crashing everything you've done so far. You no longer have the time to think about the problem, you're too busy choosing a solution!
Piling up still.
Maybe a new framework would solve everything? Look, these guys did it using something else - give it a shot?
Halfway rewrites and refactors, still piling up.
You wake up in the middle of a night crying about the monster you didn't want, but still have made in the process.
What now?
We've, as a dev society, forgotten how to find solutions for our problems. Look at the problem. Think about the simplest possible solution for your problem apart from the solutions that are offered. If those two align - go for it, that's what frameworks are for. If not - do it yourself. Think about scaling up, think about a complete shift of project focus - change is a fact of life.
Don't be afraid to start anew if you see that the things aren't going how you'd like them.
And don't, DON'T, do trade offs when you don't have to. They'll come around and bite again.
Top comments (0)