Discuss the problem, not the solution

As a technical person, I love to discuss technologies. And as the discussions go on, it’s usually comparison types: JVM vs. .Net, Java vs. Kotlin, Go vs. Rust, Maven vs. Unspeakable, etc. However, it is very easy to fall into the quagmire of merits and flaws. About our beloved toys, talk for hours about them, and never come to a satisfactory agreement.

A few years ago, I worked as a “solution architect”. There are different job titles, For example:Solution Designer, and Solution Engineer, but the goal is always the same: find the “best” solution to a problem that, most of the time, a Business Problem.

The work went through the following stages:

  1. address the issue
  2. Evaluate Alternative Solutions
  3. Choose the fittest. Sometimes, this step is the responsibility of the stakeholder.

I can’t remember how many times I saw people skimming through #1 or skipping it altogether. Here are some anecdotes to illustrate my point.

“I want a drupal”

At that time, I was working for a public administration. Don’t allow me to tell you which one in particular. their process is essential Every project must involve a solution architect To implement the above workflow.

One day, a project manager requested to meet with me to discuss a new project. He describes the business problem to be solved as follows: “The IT director of X department wants a Drupal. He has a lot of political power, so let’s get the ball rolling.”

Needless to say, I was a little more surprised by his approach. I tried to discuss the underlying problem with no success. He didn’t want to solve the underlying problem: he just wanted to follow the director’s wish.

Due to the bureaucratic nature, they followed the process that required a solution architect to validate a solution. He only needed me to approve the solution to the director’s wish. I left the room; I don’t remember exactly how it ended, but I didn’t take anything for granted.

As a side note, people whose role is only to serve as a proxy for others Very little Zero Negative cost benefit in organizations. Some organizations attract them more than others. For example, organizations with no competition suffer no consequences for low ROI and are attracted to very, For example:public administration.

.env files or not

I recently stumbled upon another example. A Google engineer wrote a post quite provocatively titled “Stop using .env Files Now!”. In the post, he told about the problems of .env How to solve them using Files and Configuration Server.

In response, another author made another post, titled “Continue Use .env Files As Usual”. As you can imagine, the author focuses on explaining that .env The files are acceptable and describe the issues with using the configuration server.

The initial post barely describes the problem, accelerating it into a short section. And in it the author writes:

I don’t have to explain why it’s bad

Sorry, but not sorry: actually, you do!

To be honest, debunking posts doesn’t work any better. Both focus on their most beloved solution, but neither does an excellent job of explaining their problem in their context.

PS: The underlying problem is that .env File management doesn’t scale. For an organization the size of Google, this is a big issue; For a small organization, they are fine.

Microservices as a Solution to a Problem Not Many Have

The microservices craze is hard to ignore. Many people comment on the pros and cons of microservices; Very few people write about why they implement them.

In previous posts, I have always been careful to explain why microservices are a terrible idea in most organizations. Maybe I didn’t discuss the problem that microservices solves, so here it is.

Successful organizations thrive. Most of the time, the team of developers grows with it to support business development. At one point, the team must be split into several sub-teams to handle development. Yes, there’s the rub.

Now, a lot of developers have to work on the same codebase. Historically, we handled this complexity as follows:

  • various development flows, For example:git flow, github flow, gitlab flow
  • A dedicated person to manage the complexities of release management

My experience has shown me that this approach adds up to a point. When the number of developers reached ~70, I noticed synchronization issues with teams of experienced developers.
Maybe others have a different experience.

In any case, this is the main problem we need to discuss. Only then can we decide which options can solve the development teams development.

Questioning the problem in technical support

The problem should also be discussed first in technical support. Support gives direct answers to frequently asked questions. I believe that’s the worst thing: it can skip the underlying problem altogether and provide a subpar solution.

Here’s an example taken from StackOverflow:

So I want to add a project that is pulled from git and then built using maven, the thing is that their pom.xml uses both a private and a public repo, they asked me to make it private Said to delete the repo and it works but I’d prefer to automate the build process with Jenkins

– How to remove repo from pom.xml before build

The answers focus on how to remove stuff from pom.xml because that’s what the person asked. But the problem is different: it’s how to create a project that references repositories it doesn’t have access to. Removing XML lines is one solution among many, but I would argue that it is not the most elegant.

I would suggest perhaps configuring a mirror in Maven’s settings.

five voices

In order to focus on solutions rather than problems, I think one should take the five approach:

Five Whys is an iterative interrogation technique used to explore cause-and-effect relationships of a particular problem. The primary goal of the technique is the “why?” To determine the root cause of a defect or problem by repeating the question. five times. Why the answer to the fifth should reveal the root cause of the problem.

— five voices

IMHO, why doesn’t one want five to talk about the problem instead of the solution. One pair of them is enough. By following in on the solution to the problem, you’ll uncover a lot of context and possibly turn the argument to an open-minded stakeholder.

Additionally, you can see that in some cases a non-IT solution would be best suited. Remember that the best code is no code.

conclusion

Engineers love to talk about their pet solutions. Still, it’s useless to disagree about a solution without context. It’s even worse to agree on a solution without discussing the problem.

Discussing the problem gives invaluable insight into what the problem is. If you want to bring in more value, you should spend more time asking what the problem is.

Leave a Comment