loading...
Cover image for A Wrong Answer is Worse than No Answer

A Wrong Answer is Worse than No Answer

laurieontech profile image Laurie Originally published at tenmilesquare.com ・3 min read

Consulting is an interesting business. You don't always get to see the full lifecycle of the project you architected. You move around companies and tech stacks and constantly change the role you're playing on a given team.

But what's surprisingly consistent, are the problems you encounter. I've written before that most technical problems turn out to be people problems. But a large part of that is due to communication. So let's talk through some of the most common issues.

Poor problem definition

The first thing we see is that people are proposing solutions without defining and refining the problem they're trying to solve. This can be a challenging thing to do!

Defining a problem involves decoupling all of the related issues and focusing on the root cause. It means recognizing all of the different stakeholders and prioritizing the pain points the solution needs to address.

If important pieces of the puzzle are missed, the solution won't adequately address the issue.

Wishful thinking

Problem definition is tightly coupled with wishful thinking. This is when the team members find themselves trying to oversimplify a problem so the solution is comfortable for them. We can "just" do this. We only need to add this. It's really not that big a deal, we can get around it with this new tool. In some cases, it can go so far as saying "we don't have a problem at all".

Often, they're ignoring the messy, people parts of the problem.

Adding Complexity

The flip side to this is when team members want things to be complicated. There are various reasons for this. Either they have trouble separating the concerns in their head. Or they want to own a bigger problem and solution for some sense of job security.

Whatever the reason, this is just as common as wishful thinking. Like I said earlier, defining a problem is incredibly important, and there is a reason a lot of teams skip over this step.

Lack of broad knowledge

Once a problem is defined, the instinct is to solve it. But chiming in with a solution right away is rarely the right course of action. That's because your response is always going to be based on your existing knowledge. Sometimes that's sufficient, but often it's better to do some research.

Perhaps you're well versed in all the potential solutions, but are their newer ones? Have existing technologies made changes that no longer make them a fit? Are any of your options improving their community support or other positive changes that would put them into consideration?

Overly opinionated contributors

This is the point at which everyone comes back to the table and starts making recommendations. And in most every team there will be one person who did slanted research. They may have checked out the options, but they did so with the determination that their favorite tech was the clear answer.

You need people besides those voices. Your most valuable contributions will be those presenting options, listing pros and cons, potential risks, etc. You can get spin from marketing sites, or product representatives, you need a real-world solution and that's what you're looking for from your team members.

Ignoring situational considerations

Another thing that may come up when examining solutions is team members who consider technical purity only. Real-world solutions require a lot of different inputs.

You want to pick a path that accounts for existing team knowledge, time and cost limitations, available community support, etc. Discounting these considerations means the solution won't be viable.

What can we do?

Asking a question without the full scope is problematic. Getting the wrong answer and running with it causes more problems.

Define your problem, take the time to actually consider your options with real-world constraints. Then figure out the best way forward for your team. Not the team you wish you had!

I'm confident in saying that avoiding these pitfalls will have a dramatic effect on the success of the technology you build.

Discussion

pic
Editor guide
Collapse
carsturdy profile image
Carson Sturtevant

To me, it seems that if you suggest a solution that you later realize doesn’t work then you would seem more intelligent admitting its wrong rather than asserting it isn’t. It’s ok to be wrong sometimes but admitting when you are is what truly matters.

Collapse
laurieontech profile image
Laurie Author

Absolutely. And the title is a bit tongue in cheek. You can't guarantee a correct answer, but some of these behaviors ensure a wrong one. And others help make the possibility more likely.

Collapse
joeyhub profile image
Joey Hernández

It might not be a comfortable realisation that the problem is people. People who got it incorrect in the first place and who might not be able to do otherwise.

When it comes to people problems then it is easy to look at it as a matter of skill. That is an easy problem. Bring in someone able to solve all the problems no one else could or who can solve the critical problems better. That's nothing more than filling a void.

In many cases people problems are more complicated than that. People's emotional needs or bad habits do often lead to disaster.

When you enter such an environment for nearly every case you find something wrong the champion of that decision will find you before you know what's going on and defend that wrong decision to the death.

Job security is indeed often the name of the game. The paradox is that the more someone does in the name of that cause and not the task at hand the more it is that they have to go if you want any chance of setting things straight.

Team has become a bit of a toxic word today. It has been mistranslated to everyone with the false assumption that a team can always exceed individuals or render individuals immaterial. A single individual can decide the fate of a project for good or for bad.

I see people throwing out something if one member on the team doesn't get it. The team of today is only allowed to perform up to the level of the weakest member.

At the same time people also lay on the buzzwords thick and no team in hell has a chance of doing all that stuff properly or with return on investment.

I've been on a few dysfunctional teams where I'm the senior programmer miles ahead of everyone else and have had to explain to people if all of this stuff is too much for me it's too much for anyone. As in focus on writing code that actually works first before trying to implement every design pattern in the book turning a hundred line program into a ten thousand line program.

This is because many managers just copy what everyone else is doing and assumes that results in success. When they're not looking at the problem they can usually be found looking at what Google is doing next and what's presently hot or trending.

I see people behave in ways that suggest to me their minds have been broken. When people are put under such unreasonable demands then it is easy to see why. I have the confidence to speak out about it but I don't know what's going on in the minds of these juniors. Their minds are probably buckling under the pressure.

For a non-technical person it is extremely challenging to work out who is in the right and the opinionated loudmouth can reassure them spitting out several dozen buzz words and abstractions they heard about a minute.

I'm not sure technical purity is always that. I hear people go on about design patterns and other things.

It sounds an awful lot like technical purity with a lot of breadth and depth but on investigation it's theory separated from practical concerns with the motivation for it being that those terms can be found on most job postings and are also trending in the blogosphere.

I am very much about the technical purity but I also realise it doesn't mean to me what it does to others. To me it means minimalism which you need because even if things are kept uncomplicated they soon become complicated and if you made things complicated from the start now you have two problems.

People also have two very diverging definitions of making things complicated.

It's not always obvious to people what makes things complicated. Many people think the complicated thing is the simple thing. You commonly see this with people using a million line framework to wrap a one thousand line API.

It is not possible to truly understand simple and complex without firsthand experience.

Those words are lost on anyone who possesses little more than an abstract understanding of the problem.

I have always considered my team's existing capabilities when embarking on a project. I often make certain sacrifices to take advantage of this.

When I do so I know I am making a sacrifice of one thing for another.

I'll ask someone what they're familiar with then that takes a part in my decision making process. It is not a deciding factor but one among many.

What is sad to see are people arguing for something with the introverted reason being that it is familiar to them but with the extroverted reason being that it is technically superior.

Sometimes motivations are more sinister. Someone will argue for some newfangled thing because it will reset everyone's score.

Managing programmers can be unpleasant as many behave in certain ways for their own cause but they wont openly declare their motives. Given many will respond to their emotions it wont be something they even thought through.

Collapse
kleene1 profile image
kleene1

This is quiet cool defining th problem is really important. Im heading in to do more kind of stuff like this and i can see its important to get stakeholders to know what you are doing and if it should be done.. will a good explanation of what will be affected beyond just a technical definition (that i would understand). I will see how i will have to step back. I've tried to see how other developers or rather senior developers do it and talk to people invovled.

Collapse