What were you trying to achieve?

A senior engineer joins a team. Before long, they start noticing weird quirks in the codebase: two ID fields on the same DB table, one-off Redis cluster outside the company’s AWS, React components organized in a very unorthodox way.

So they turn around to the teammate who has been on the team since the beginning and ask: “why is it built this way?”

But “why” is a terrible question for 2 reasons:

1. It makes people defensive. Subconsciously, the engineers who built the system might feel threatened. They’ll start making up arguments to justify the system’s current shape. “Well, Redis on XXX provider is actually superior because …”

2. It doesn’t help you decide what to do with the system. Is it still the best solution or should you do something about it?

Here’s a better question: “what were you trying to achieve?”

It focuses on the intent, not the means of getting there. Maybe the team was trying to scale this experiment really quickly or tried to align itself with other teams in the organization. You’ll see the current solution in its context.

Then you can easily compare the original intention and the current company goals. Maybe some of these things are not relevant anymore, and instead of lengthy migration of the Redis cluster, the right thing to do is to remove it altogether. Or ignore it, and focus on the things your users really care about.