“It Depends” Is the Phrase I Hate Most

Introduction

“It depends.”

I don’t know when it started, but this phrase became the all-purpose answer for engineers. How should the architecture be designed? It depends. Should we adopt microservices? It depends. Which framework should we use? It depends.

That’s not wrong. In software development, there is no silver bullet, and every technical decision depends on the situation. But this phrase does nothing to help move a project forward.

In Japan, engineers like to use the phrase “technically possible” to mean that something can be done, but they may not want to do it, so they use it as a polite way of refusing.

So correct that it’s meaningless

You state an opinion, and the other person replies, it depends. You press further, and they give you another it depends. In the end, everyone reaches a consensus that is no consensus at all, and the meeting ends.

It depends is almost always correct in almost every situation. So saying it is basically the same as saying nothing at all. It’s like when someone asks how to control the heat while you’re cooking, and you reply, “The key is the heat.”

On the other hand, if the other person says It Depends, it may also mean that your goal is not clear enough, so they don’t know how to make a decision in the current situation, which leads them to give a vague answer.

That’s why, when I’m facilitating discussions, I try to share the purpose and background in advance as much as possible, to make sure everyone is on the same page and can find a solution. You can also take a look at an article I wrote before — Basket and Spear — are you seeing the same view as me right now? Or are you looking at an orchard while I’m looking at a jungle?

Why decisions can’t be made

There’s nothing wrong with not having an idea. In the book The Soul of Perfect Decisions, it says that situations can usually be grouped into these three categories:

• Decide immediately
• Insufficient information
• Decision deadline

I think the reason someone can’t make a decision or offer an opinion is usually because of insufficient information. And that’s also the easiest to resolve, as long as both sides can close the information gap. Not having an idea can actually be a way of expressing an opinion too. You can say, “I don’t have enough information to judge.” If you’re not familiar with the domain, you can say, “I don’t understand this area very well, so I’ll follow your lead for now.”

The next time you encounter “It Depends,” you can ask:

1. So, what’s your opinion?
2. What information do you need to help you make a judgment?
3. What’s the purpose of saying this?

How do you actually move a project forward?

It Depends was once my standard for judging whether someone was senior. Because it represents making trade-offs, clarifying requirements, and no longer stopping at simply building the feature.

However, this maturity can also become the arrogance of refusing to take a stance. Because there are too many things to consider, you become afraid of making mistakes, so you sweep everything that should be addressed under a single It Depends.

That’s self-deception. In the end, the person who says nothing occupies the moral high ground, while those actually discussing things look immature.

The real way to move a project forward is to responsibly bear the weight of It Depends. Organize the arguments, clarify the needs of stakeholders, prioritize, fill in missing information, and communicate proactively.

• Which side should take priority this time?
• Under what conditions would the priority be reversed?
• Who bears the cost of this trade-off?
• If the judgment turns out to be wrong, which direction is easier to recover from?
• Is this a matter of principle, or just an exception for this case?

When you push the discussion to this level of detail, “balance” becomes something actionable. Then people make decisions and take responsibility for the consequences. If it’s wrong, you review it, adjust, and move forward again.

The same principle applies to saying “results matter more than process” — it’s easy, but you can’t use that as an excuse to avoid improving the process. You can get results through short-term sprints, but you can’t rely on sprinting forever. If you don’t improve the process, you’re borrowing from the future.

Let me give a few examples. In the projects I’ve taken on, I’ve encountered discussions like these:

• Should we use MySQL or Postgres?
• Should we use a Monorepo or separate repos?
• What programming languages should the front end and back end use, respectively?

These are discussions with no single correct answer. If you let the team debate them, they can easily turn into meetings that reach no conclusion.

“MySQL and Postgres are both fine.”

“Monorepo seems easier to manage, but separate repos make sense too.”

During a project, what I dislike most is this kind of discussion that can’t move the project forward. So I prepare materials in advance to persuade the team. On the surface, it’s a meeting to decide the tech stack, but in reality, it’s a way to communicate my conclusion to the team. As for how to evaluate it, you can check out my previous articles:

Boring Technology 通常有「引入某個新技術」可以解決既有問題的想法，大多代表開發還沒有想得足夠清楚而已。不過要體悟這件事，通常需要時間積累。從碰到新技術眼睛會發光的少年到變成油光滿面的中年大叔。 random

I try to shoulder the full weight of It Depends and explain to the team why I’m making that decision, including recent trends and what technologies are commonly used in the customer’s environment. (Of course, you can also dress up your own preferences and steer the team in the direction you want.)

Even though that means I have to bear the risk of making the wrong decision, it’s still far better than people who only say “It Depends” and “See? I told you so.”

I’ve been burned a few times before. Even though I knew the team’s discussion wasn’t going well, I didn’t offer my own thoughts. I subconsciously assumed that speaking up wouldn’t help anyway, and then I just vented on SNS to feel better and let it go.

Conclusion

Don’t keep saying “it depends” without specifics. Clearly express what the “situation” is: what is the current context? What should be emphasized? How should a decision be made so that it helps the project move forward? It’s easy to stand at a distance and sneer. Getting your hands dirty, convincing others that your proposal is feasible, and pushing the project forward step by step while carrying the weight of “It Depends” is much cooler.