ITIDO

In our daily life, we face different problems and dilemmas. Choosing the right approach for solving each is extremely important for two reasons. First, it determines whether we will cope with the particular situation or not. Second, if we do cope, whether we will do it in the most appropriate way or just end up with a temporary solution. In the long run, it is quite possible this will turn out to be the wrong decision. This situation is often experienced while working on a software project.
My experience with algorithms, data structures and statistical approaches used in AI has greatly influenced me to apply know-how from these fields in my daily life.

Do it like the Romans

One of these approaches is “Divide and Conquer”. It is a technique where a problem is broken down (“divided”) into smaller parts similar to each other and to the main problem. Then recursively we solve (“conquer”) each of these smaller problems separately and combine the solutions into one that solves the main task. Many software algorithms in Java (and not only) use this technique for solving a problem. Among them are the Quick sort, Merge sort, Closest Pair of Points, etc. It is also used in the Java implementation of parallel execution of tasks in the Java fork/join framework.
At first, this mostly technical definition may seem confusing and not very helpful. Nor does it say exactly how to resolve a given case. Also, this technique cannot be applied in the same way to everything. However, the main idea behind this approach is remarkably simple – breaking down a given problem into small parts! Even if they are not uniform, even if they are not similar to the main problem (as is the requirement and the definition of this approach in the specialized literature) this gives us a good start.
Any case study, no matter how big, complex and messy, could be broken down into small parts. The breakdown can continue to smaller and smaller pieces until we reach a point where each one of them is already so small and simple enough to be resolved independently. At this stage, when we already have many but relatively simple problems, we can combine this approach with another one appropriate for exactly such situations: the Pareto Analysis!

The 80/20 rule

According to the Pareto Analysis, 80% of all problems are caused by 20% of the factors that cause them. Named after Vilfredo Pareto, a renowned Italian economist and social scientist, this analysis identifies the issues that have the greatest impact.
These proportions, of course, are not set in stone and can be considered only as a guideline. The Pareto principle mainly shows the lack of symmetry that often occurs between the work or efforts that we put in and the results that we achieve. For example, anyone can find that approximately 20% of the effort they put in generates about 80% of the benefits they get.
Conversely in the context of problem solving, we can say that 80% of the problems can be solved by dealing with about 20% of the factors or causes that give rise to them.
So what we have till now is two relatively simple techniques like “Divide and Conquer” and the Pareto Analysis which combined together could lead us to excellent results.

Using the methods together

The easiest way for their combined application is as follows:

1. Break down a problem into many smaller and simple ones.
2. Further split them, if necessary, so that each of these smaller problems is small and easy enough to be solved independently.
3. At this stage, we apply the Pareto Analysis. We analyze the main causes for each of the problems. It helps to ask why and how each cause creates a given problem.
4. Put a score on each of these causes that reflects its importance (e.g. from 0 to 10 where 0 means “not important” and 10 “extremely important”). A frequency of the cause could also be used.
5. Group the problems that are caused by similar factors. For example, if three problems are caused by, let’s say, the lack of staff, then they can be analyzed together and placed into one group to the corresponding cause or factor. Thus, we have a list of different causes and a set of problems associated with each one of them.
6. Sort the reasons in descending order by placing the ones with the highest score at the top.
7. Identify the causes (along with the corresponding group of problems) by collecting their scores until we find the causes causing 80% of the problems. In the most common case, these are about 20% of all identified causes or factors.

Here is how a sample distribution may look like:

In this particular case, around 70 to 80% of all problems result from four factors, i.e. 40% of all causes.

Looking beyond

Of course, there are other popular problem-solving techniques like the 5 Whys, the Lean-inspired Structured Problem Solving, the Six Thinking Hats, etc. However, I have found the combination described above strikes a good balance between ease of use and having well-grounded, actionable results in the end. By eliminating the root causes, we may find that by addressing just 20% of them, we have solved 80% of the small problems.
A point that will inevitably lead us to solving the main case in the most elegant and optimal way.

In many software projects and teams following the Scrum methodology, we could observe something similar. Many product owners (POs) often break down a big story into smaller ones so that it can be finished during the sprint. This way many developers could pick up one of the smaller stories and combined together they accomplish the initial big task. They are acting in fact exactly as in the Java join/form framework.

Yordan Donov, Senior Software Engineer at ITIDO