Why Breakdown Problems?

We’re often presented with software engineering problems that are somewhat vague, hard to get started on or present a lot of potential work. This is where breaking down what’s presented to us into smaller pieces will help you tackle the complexity presented, try to understand it and imaginably reduce it.

The more a software engineer is exposed to problems to solve. The more you appreciate breaking them down assuming the complexity of problems increases overtime. This article will go through the why and not the how. The how was covered in other articles of mine though will briefly cover how you may break problems down. Those other articles are:

The audience is any software engineer no matter how junior as you are.

Ok so what is breaking down a problem? Simple, basically the process of taking one large watermelon and starting to slice it. Each slice is a separate part that maybe worked on separately and can be reasoned upon separately. A critical part of planning.

It is not just limited to one round of slicing. For each slice, you can go slicing further until the slices are trivial enough to be implemented by an engineer without having to deal with the rest of the problem’s complexity.

So why breakdown problems? Essentially to translate a piece/s of work into workable tasks that can be done by engineers.

That was the main reason. Now you might say why all the article for just that. True. It is not just for that. You learn more about the problem by breaking it down. Obvious issues stand out right away like using a combo box that isn’t supported whereas the non-obvious can only be surfaced when breaking down a problem. A non-obvious obstacle would be how to link data between 2 or more parts of the problem.

Patently you won’t surface everything from the start but the more you practice the more you can surface as a result of experience.

Third reason is estimation. Once you understand how many parts are required to solve a problem, you will be able to come up with an estimate about how long it would take. The estimate may not be accurate though serves the purpose of letting stakeholders reason about how long it would take, what blockers exist and what could go wrong.

In essence, if you digest those reasons above and think of what they mean then you will come up with the following realisation, problem breakdown:

Reveals the different parts that constitute the system and how they interact
Makes clear what is required to work on and finish the broken down tasks
Reduces complexity involved when thinking about pieces of the problem
Transforms parts of the problem into units of code delivery which can influence how you want to deliver the code and how to test it

Of course different people should have different responsibilities while solving a problem. An individual contributor should know the high level and how components relate but should be expert at the level they’re operating on. A project leader should know the high level in and out interfacing with/between individual contributors and other stakeholders. The point I want to drive home is the fact that you should not break down problems and forgot the high level problem overview or else you didn’t gain anything.

Another thing I want to deliver is you should be aware of the size of the problem. A larger problem deserves more planning and breakdown than a problem that can be handled in a short amount of time. Bear in mind, business decisions should also have a priority when solving problems and breaking down as well as designing software to be perfect often is a result of too much planning and hence too much breakdown of a problem. It is always a balancing act.