Separating problems from solutions

As a preface to this topic, I would like to describe what a simple development process would look like. Commonly, there should be some project management where large chunks of work are broken down into smaller chunks of work. Call them tickets, tasks, user stories, milestones, or OKRs, there will always be a list of things to be done and marked as finished after completed.

After the strategy is set, tools can come to the scene and contribute with better organization, visibility, collaboration, or time-saving, although nowadays I see many times people using tools as solutions, and adopting whatever strategy comes with the tool, and even changing the solution of their business to fit in the box the tool came within. I have been challenging this attitude every time I witness it because I believe that you as a problem solver and a solution designer, carry the responsibility of making a conscious choice over the strategy instead of only pushing the buttons or following the steps demanded by any tool. Should a new tool offer a concept that's new for you, people should take a step back, learn about the strategy, then come back to the tool and see if it fits their business.

But let's focus on the strategy. Problems found in non-complex projects are usually easy to be solved, and the solution is pretty obvious and understandable by anyone across multiple levels of the business, from technical to non-technical. Not much needs to be said and very little needs to be done. I wish every problem-solving could be that simple and I agree that we should prioritize the simplification of the problems or break them down into smaller problems until the solution becomes simple and obvious for everyone involved.

However, problems are not always simple and scenarios grow into complexity. Solutions no longer need to satisfy only the current requirements, but also need to be scalable or "future-proof". The number of dependencies and risks of side effects grows and must be considered. At this point, more attention must be given to understanding the problem. When the complexity of the problem is neglected, the real issue can be obfuscated by solution ideas, and solutions are not well explored or planned, given they must share space or compete for attention with the problem description.

Isolating the problem

Problems should describe only what is the matter of the issue and what is wished to be accomplished. But here is where lies the danger. When describing the valid state to be achieved, we must be careful not to provide the most obvious solution along with the problem. Especially in scenarios where two different teams or departments are assigning problems to each other, the ones describing what was experienced when the problem appeared might not be the ones specialized on how that component or that part of the system was implemented, therefore, limiting the range of the solution to that simplistic view from the perspective of an outsider.

My favorite method to isolate a problem, is by defining three questions: Who has the problem, What is the problem, and Why is it a problem?

The question "Who" will be providing the context in which that problem happened, making it easier for the scenario to be recreated and the problem to be reproduced at free will. It will clarify whether it was a user with a specific role in the graphical interface, or another system consuming an API endpoint.

The question "What" is usually the easiest to be answered, given it provides clearly what shouldn't be happening and what should. This is usually turned into the acceptance criteria for the problem solution.

The most neglected question is "Why". People are normally conditioned to do their jobs and not question other people's decisions or departments. They might not be happy about it, but they seldom stand up against it and try to fall into a common agreement. "It's not their job to ask questions". Nevertheless, questioning "why" something is an issue can open doors to topics that will be contributing to better management or better solution. Knowing "why" allows us to better calculate the blast radius caused by the impact of that issue, and therefore, priority can be identified and help us in the management of multiple other problems, deciding which should be solved first. In my learnings, this question became so important to me that I use it as a criterion to identify the seniority of individuals or teams: Juniors ask "how", proficients ask "what", and seniors ask "why".

Limiting the problem to only these three questions is a good way to start displaying trust and alignment between people and departments, allowing teams to grow autonomy. There is a very interesting illustration from the Spotify model that I would like to link here:

https://engineering.atspotify.com/2014/03/spotify-engineering-culture-part-1/

I am not suggesting the adoption of the Spotify model, but I find that chart in specific suitable to make my point.

Some examples

Scenario 1: "The website is not loading properly for customers in the EU"

• WHO: Customers in the EU

• WHAT: The website is not loading properly

• WHY: It is considered a problem because it is negatively affecting the user experience for a specific group of customers.

Scenario 2: "The checkout process is not completing for some mobile users"

• WHO: Some mobile users

• WHAT: The checkout process is not completing

• WHY: It is preventing some users from completing their transactions.

Scenario 3: "The database connection is timing out during peak usage hours"

• WHO: API clients

• WHAT: The database connection is timing out

• WHY: This is causing a bottleneck in the system and negatively impacting the integration between applications.

Scenario 4: "The search functionality is returning irrelevant results"

• WHO: Users utilizing the search functionality

• WHAT: The search functionality is returning irrelevant results

• WHY: It is preventing users from finding the information they need and is negatively impacting the user experience.

Designing the solution

For the solution design, there is only one question to be answered. "How".

There are many ways of achieving a goal, and multiple strategies and different levels of complexity can be adopted. The best of it is that now there is plenty of room for one or even more solutions to grow. What are the values that each solution can offer? What must be learned? Prototypes, or Trade-Offs.

When the solution is detached from the problem, it can be better stored, documented, and reused. I could mention several methods like Design Thinking, ATDD (Acceptance Test Driven Development), ADR (Architectural Decision Records), BOM (Build of Materials), and the list goes on. The only limitation is, of course, how much time you have and what resources are available.

Don't be deceived by the lack of time. Coupling the solution with the problem can be tempting, but it won't save you time. Very likely it will cause the opposite effect. It is very common to not have time to implement a proper solution, but splitting the fields of problem and solution hardly costs any extra time, and can actually help in providing creative and reusable solutions, which can actually save time.

Complementing

This is a concept very easy to extend and complement accordingly to every team's criticality and time availability.

Here is a visual demonstration of what it could look like:

In computational systems, we learn the importance of the separation of concerns is, and how decoupling subjects can help with having a more lucid comprehension of complex situations we face. Given it is common knowledge to break big problems into small problems, then why not tell apart the solution from the problem, making it even smaller?

For development teams, refining the work before jumping into the implementation is a huge step toward quality of work. Breaking down the refinement phase in a way that provides the opportunity to design the changes before implementing them could be a great next step.