Embrace the non-judgmental “why?”

Silhoutte of a road post at sunset.

I often see (and am guilty of myself) people disparaging choices made in the past. “That’s so stupid,” they say, “why would anyone do that?” But that’s not a particularly helpful approach. The “why” is too judgmental. Make your “why?” non-judgmental.

Most people don’t make bad decisions on purpose. Even if the decision is bad, the person making it thought they were doing the best they could. It’s more likely that the decision was good in the time that it was made. The context that made a decision good will change over time. What is a terrible decision now probably made a lot of sense in the past. Ask “why?” to understand the context so that you understand the decision.

The USB example

For example, USB cables have long been frustrating. Somehow it takes three tries when there are only two possible ways it could go. Not until USB-C did the dream of reversible plugs come true. But it’s not like nobody ever thought of that before. The original USB connectors weren’t reversible because the inventors wanted to make it cheap. Doubling the wiring would have increased the cost and risked the “Universal” part of “Universal Serial Bus”. They weren’t trying to design the perfect connector, they were trying to design the best connector that vendors would use.

Now, you can argue that vendors would have adopted the most expensive reversible model in equal numbers. Perhaps. We have no way of knowing for sure. But it seemed like an unreasonable risk to take, especially since so many of the devices that ended up with USB connectors are low-margin.

In your project

When PHP’s git forge was compromised in 2021, some asked why they weren’t using GitHub or GitLab. GitLab’s community edition can be self-hosted, after all. It seems obvious, right? But PHP predates GitHub by 13 years. So at the time, creating custom tooling seemed like a good idea. The older a project gets, the more opportunities there are for past decisions to make no sense in the present.

As you look at decisions, be they technical or process decisions, in your project, ask yourself what context exists for them. Even better, ask the people who made the decisions or consult a decision log if you have one. If you understand why a decision was made in the past, you can make better decisions for the future.

“What is the goal of this decision?” is a good starting point. Perhaps there’s a better way to accomplish that goal now that didn’t exist then. The “business” justification may be unchanged, but the method by which you achieve it no longer makes sense. One good sign of this is the unpaved path: the paths that come from people walking where the sidewalks don’t go. If your community is skipping or modifying part of a process, that can be a good sign that the process no longer meets the goals.

Photo by Javier Allegue Barros on Unsplash.

Ben works on open source strategy at Docker and was previously the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.