Breaking problems down

Some technical problems can get quite challenging. It's pretty common to feel like you dont know how to approach them or even panic. Especially if you are starting on technology. Even the most accomplished and experienced feel the impostor syndrome. IMHO if you do not panic is already 90% done 😉, then the next important thing is to keep going. Small incremental progress is essential emotionally wise in the sense of confidence-building. Small wins can be addictive. The first steps are often the most difficult because we are talking about a technical discovery process.  The tech discovery process might sound like something new and fancy, but actually, we are talking about something as old as the rocks: Analysis. But! How do we do this analysis? Which leads us to the questions such as: How to approach complex tasks? How to break problems down? 

Grasping the Problem

For Lean: Requirements are very tricky; after all, they are just decisions that someone made. Is very common for people to make a list of requirements and them blindly follow them. For this reason, sensing the problem is much more effective. You need to judge the issue. Yes, see what's real and what's not. This is a thinking and discovery process that often cannot be done in 1 day. 

Understanding the Landscape

I found it very productive to always understand the landscape. Let's say you are building a Social Network, and you need to use graphs. There is a world of possibilities. For instance: should you use algorithms and data structures, or just rely on graph DB? IF so, which graphic there are many out there. As soon as you start looking into the solution, you will realize you need to understand more about the problem. 

Often people think that talking about solutions is terrible. IMHO is awful if you decide it pretty quickly without much due diligence. In that case, yes is horrible, but if you use that as a mechanism to show what you dont understand about the problem space. Looking for a solution at an early stage to understand what you dont know could be helpful. However, there is a trap there because sometimes you could be trying to put a square peg on a round role. Thats why you need to understand better the nature of the problem you are trying to solve.

Building Scenarios and possibilities 

After grasping the problem and understanding the landscape, you can start scenario planning and think about possibilities. More possibilities are often better because you will be doing tradeoffs if they prove accurate or valid. However, you need to be careful in discarding possibilities; I saw over and over people dumping good options because they lack understanding. 

Code Analysis and POCs

Looking at the source code is a must-do step. Reading code is always much harder than writing it, so you can and should take notes, make simple diagrams in order to fully understand what's going on. Debugging end-2-end calls from the edge to the core is always a good idea for understanding. 

POCs are ways to validate your scenarios. When you think about scenarios, they might be possible or not; when we do POCs, we can validate if the scenarios can work. Even doing POCs, you will need to do more analysis; let's say you need to migrate consumers, you will need to analyze the impact on the team and if your solution will work smoothly with them or not.

Tradeoffs analysis

Now you have more confidence, you need to perform tradeoff analysis to see what solution or possibilities make more sense. Tradeoffs are not that hard to do - the tricky part is finding the correct variables to look for. There are always standard variables you can look such as:

 * COST - Would we be saving or increasing costs?

 * Complexity: How complex the solution is?

 * Migration Complexity: Do your consumers can get that quickly or need a complete re-write? 

 * Isolation: How much your solution is isolated and abstracted, meaning how much flexibility is left for the future if you need to change something? 

For each problem space/domain, you will have other variables or properties you will need to look to mention a few ones like Security, User Experience, Developer Experience, Performance, Scalability, Reliability, and many others. 

Choosing the solution

Choosing the solution is also tricky since, besides all technical tradeoffs variables, you will need to look for competing priorities from other projects, people availability, business appetite for investment, pressures for the market, competitors, compliance, and many other variables. Often the winners are on the sweet spot of cost, benefit, and priority. 

There is a variable that can trump all this impact, meaning you might be delivering something critical to the business by a new capability resulting in more revenue, user base increase, which might justify the complexity and high investments. 

Cheers,

Diego Pacheco