Divide and conquer is a very useful strategy that you can use in a range of problems.
The first time I heard of it was in reference to the algorithm to break down problems recursively. The idea is to break down a big problem into smaller problems that are easier to solve, and then solve a slightly bigger problem on a partially solved data set. If you don’t know about the algorithm, you can read about it here: https://en.wikipedia.org/wiki/Divide-and-conquer_algorithm
The expression seems to have its origins in Greece, and referred to politics, where people would seek to divide their adversaries in order to acquire power. Or, as the quote goes:
There is only one way to eat an elephant: one bite at a time.
I know that this may seem obvious to you, but I have seen many engineers entangled in large problems that seem unsolvable just because they don’t apply this very simple strategy.
Dividing tasks and projects
Projects in development teams are usually divided into tasks because everyone with enough experience to lead them will already know that doing otherwise is shooting themselves in the foot.
The less obvious part is that tasks can also be broken down. Whenever you start working on a new task, consider how the task can be split into smaller parts, or subtasks. How exactly depends on the task, but the general advice is to break down tasks into the smaller chunks that make sense.
In some very extreme cases, you may decide to have a subtask for a single line of code: if this line of code has value by itself then yeah, it may make sense. Remember that you will have to add automated tests and your peers will have to review the change, so isolating this change from other code may be the best approach. On the other hand, if you create one task for every line of code that you write, maybe you’re overdoing it.
A huge benefit for you when breaking down tasks is that the brain is focused on one small problem at a time. One major difference between current and future senior engineers is that those who are already senior do this all the time, and maybe they have mastered it so well that they do it unconsciously, but they do this regardless.
One common outcome of following that approach is that you will have a list of things you need to do to complete your work. And if it was a complex task or project, you would have certainly identified some additional tasks that you had not thought of before. This is a great win, as uncovering unknowns as early as possible will save you lots of trouble down the track.
Another frequent result is that you cannot identify how to split a problem. If this happens to you, the most common cause is a lack of understanding of the task, the problem, or how to solve it. This is also a great outcome! If you don’t know something, you want to find out as soon as you can. Then, you can do an investigation spike, prototype, or whatever you need to do to gain the knowledge that you need to split your task.
Dividing code
The Single Responsibility principle of software development establishes that classes should have a single responsibility (I will definitely talk about this in another article). I recently encountered a class that was facing this problem, and what made it clear was how hard it was to add unit tests for it.
When the principle is broken, the solution is simple: move some code into its own class. Divide and conquer. After splitting the class, testing the logic in isolation was extremely simple.
Whenever you have code that is doing too much, or that is hard to test, you have a good candidate to divide and conquer it.
Getting into the habit
There is nothing new about the strategy really. I believe that the issue is to get into the habit of thinking of this as a strategy to solve problems, or even better, not even think of it.
The key to this is being aware of the power of divide and conquer, and being able to identify when you need to make use of it. This is another weapon in your arsenal for you to use at the right time, and only through experience you will be able to time it correctly.
That is easier said than done though. In order to solve problems, we need to step back and try to find a solution that is usually technology agnostic. We like fancy tech and tools, but many problems can be solved with very humble strategies like this.
The strategy to divide and conquer has been with us for thousands of years, but it never gets old. Aside from IT and politics, it can be used in many day-to-day life problems. Next time you have a task or problem to solve, give it a go!
Cheers!
JM
Share if you find this content useful, and Follow me on LinkedIn to be notified of new articles.