Dan's Blog

Musings on code, and other assorted sundries

What Is The Right Way?

If there is one thing that engineering orgs are never in short supply of, that would be opinions. Everyone has their idea of what The Right Way™ of doing something is. Why wouldn’t they? By nature of our profession as problem solvers, we are inclined to dig into the meta of our own problems, and solve them as well. It’s a matryoshka doll of problems to solve here.

But, what _is_ The Right Way™? I know what you are thinking; “It’s my way Dan, and you are wrong to think otherwise”. Well, you are right to think that.  You are also wrong to think that. How’s that? Well first of all…

Is there a Wrong Way?

Of course there is, but it’s not what you think it is. It is pretty simple actually,

The Wrong Way™ is the way that upsets the most people.

There is a lot to unpack in that statement, so let me break it down a bit. At a high level, what are the things that upset people? It’s solutions that:

  • Don’t solve the problem
  • Didn’t get buy-in from all stakeholders (spoiler alert; engineering is a stakeholder too)

Let’s dig into that a bit more. First and foremost, we are here to solve a problem. The solution being proposed needs to… umm… actually solve it. There is a catch though; the person proposing the solution thinks this solves the problem. Why? That’s for you to find out. There are countless reasons why. Maybe they didn’t understand what we are trying to solve. Maybe you don’t understand what we are trying to solve. Why doesn’t anyone understand what we are solving for here!? Well, it probably wasn’t defined well enough. That can happen for a lot of reasons, but its crucial that everyone agrees on a problem to solve, and that the requirements for solving that problem are clearly understood. Any ambiguity in defining the problem will be filled in with assumptions; I guarantee it.

When the problem is poorly defined, the solution will be poor. So, pull up a chair, get your team together, and define that problem. Don’t worry about coming up with a solution yet; you don’t even know what you are solving for. Like most things in life, this is going to require clear communication; open, honest, and respectful communication. Be curious, ask questions. There is no such thing as a stupid question, especially when trying to model the problem.


Now let’s talk about the second point; buy-in. I know I said the dirty, business-speak work “stakeholder” here. I know you read that and you immediately think serious bidness people. But you are a stakeholder too. I am a stakeholder. Your teammates are stakeholders. Everyone who has to use and maintain this thing is a stakeholder. In other words, everyone affected is a stakeholder. Now that we have established that, I am just going to start to use the word “team” in its place, because I already feel dirty typing that word that many times.

If half of the team does not buy-in, and the other half does; that’s friction. If you are dictating your solution, and are the only one bought in; that’s major friction. I would expect this to occur while The Right Way™ is being teased out, but it should not end in friction. Prolonged friction isn’t good. It will always exist (at least if your org is healthy; but that’s a topic for another time), but it should be in bursts, not sustained. You know what sustained friction gets you? Burns. Burning is The Wrong Way. No one likes to be on fire.

It doesn’t end with friction though. The other part of this is where buy-in comes from.

Now I bet you are thinking “Dan; the right way is tested, automated, blah blah”. Yes you are right, but that’s all just meta. Stability, resilience, extensibility, etc etc are all side effects of buy in. I’m assuming you have a talented team that innately knows these are things that are needed for their buy in. The details are out of scope of this post, just that buy in is required for harmony in the solution.

That’s what I am getting at here; everyone involved needs to be happy with the solution! Thrilled? No, most people won’t be thrilled because there is no perfect solution to most problems, but no one should be upset. No one should feel ignored and unheard. The loudest voices in the room should not be the arbiter of solving the problem. The Wrong Way™ is beating the team into acceptance of a solution that they feel wont work; either through attrition, or good old fashioned force (figuratively; please don’t beat your team).

So what is The Right Way™?

Well, actually the answer is pretty simple; it’s the way that:

  • Satisfies the spec
  • Satisfies the broader team

Just like The Wrong Way™ starts with an ill defined problem, The Right Way™ satisfies a well defined spec. It actually solves the problem (go figure). Not only does it do that, but it does it in a way that all parties involved are satisfied.

The Right Way™ is satisfaction.

To be even more precise; The Right Way™ is the absence of frustration. Users aren’t frustrated with a bad interface/buggy software. The engineers aren’t frustrated with an inappropriate architecture and/or bad tooling. The Q/A teams aren’t frustrated with a complicated integration. DevOps isn’t frustrated with a poor infrastructure. The business leaders aren’t frustrated with long lead times. Most important of all, everyone feels like they contributed, and that their needs were covered.

That’s it. That’s all there is to it. Now guess what? Your way might fit the bill, but so might someone else’s. Just because it did not come out of your own head does not mean it is wrong. Judge solutions by these broad metrics; don’t succumb to the temptation to shoot down ideas just because they did not match your single idea of how a problem should be solved. The Right Way™ is subjective to the people who live with the decision.

In fact, The Right Way™ is rarely The Best Way™. The Right Way™ will evolve over time (because specs evolve over time), and that evolution needs to be driven by the broader team (because they need to continue to be satisfied).

The TL;DR you scrolled down for

The right way to do particular things is entirely subjective, but the least common denominator of all successful solutions are those that satisfy an agreed upon problem in such a way that all interested parties are happy. Happiness is of paramount importance (happy people are productive people after-all), and therefore the right solution to Problem X is the one that ends with smiles instead of tears.

So, in conclusion, when I ask you what the right way to solve Problem X is, and you say “It’s my way Dan, and you are wrong to think otherwise”, you are right! So long as Problem X is not really Problem Y; and that all your staff, peers, and leadership walk away smiling and satisfied as they bite into the juicy steak that is your solution.