Divide to conquer — a nice principle to take
When I was taking my bachelor back in college and was learning the sorting algorithms, there were a few where you had to split the array (merge sort to be exact), to ease the class learning my programming teacher told us “you need to divide to conquer”.
I enjoyed so much the idea that I first started to think how that was so implicit in our ancestors achievements and how it is applied in real life. We make small goals to achieve bigger ones and that’s a healthy way of thinking because it always gives you time to learn more and to absorb correctly what you do. Like a progressive evolution, only with patience and time you get what you need in the best way possible.
So, that got into my head for many years in many spectrums, one of them was of course programming. Everything I’ve learnt in computer science I’ve always tried to make a correlation with it. I found that
this idea was right in the bones of all good programming standards
like loose coupling, modular programming, clean architecture, OSI model, web frameworks, among many others. Everything is divided in order to delegate a job, a use case or a feature to a specific part of the system without the other parts knowing how it’s done — and the fact is that it works. Everyone applies those concepts, or try to, because it’s a natural thing to organize the stuff we do.
This idea enlightened so much my analytical thinking, my way of structuring my projects and gave me a nicer way to organize my code, now when I am programming and I’m adding new stuff I always think
how can I divide this in order to be more scalable, more modular, understandable and easy to maintain?
There is no right path to do this, so the goal is always trying to answer this question in the best way I can, following guidelines or learning new practices.
Sometimes it’s a natural way of thinking because we need to be organized in our projects, but when we face an architecture problem we really need to get deep in our previous experience and knowledge and be creative, that’s how “divide to conquer” will always be a good way to start for me. After dividing it, sometimes you need to unify them, I mean, there will be a common point where those parts are called. You have to care about the communication, how other parts of your system will consume what you just divided and that’s what I call a middleware layer (often used in network systems). Who is responsible to “redirect” to the right place or just simple joint every part as needed, like a gateway or an interface.
Of course there are downsides of doing this, if you are not so experienced, this will take time which is the biggest enemy of trying to do things right. Also, if you divide so much it can be confusing and overwhelming for new people who are trying to understand your project, even for you if you go back to the project after a while of not developing it.
Although a powerful one, mind that this isn’t a standalone principle that you can apply. You can apply lots of principles in your project to empowering it and help you and your teammates to collaborate in a more harmonious way.
It’s always a matter of balance, but I really like to apply this principle in almost everything I do.
