Share your problem, don't request features

  Thursday, October 26, 2023

I help maintain a couple of projects and one aspect I find surprising — and a bit troubling — is how often people ask for features without explaining their problem. Maybe it’s already in the name, “Feature request”.

Despite asking for a feature, often it’s not what’s needed. What’s needed is a solution to a problem and many problems have more than one solution.

I need a car

Consider an example outside of software development: A friend tells you they need a car. The problem unspoken because it’s clear as day: They lack a car. That’s all you need to know.

You’re a good friend and hand over the keys to borrow them yours. Problem solved.

Wait, maybe not so fast.

Problems and solutions

You know how kids can ask why, why, why and why, each answer triggering another question? We should do that more, because getting to the root cause of a problem is useful.

Your friend’s problem isn’t really the lack of car. The problem is that they need to get to another place. And why do they need to get to another place? Because they’ve a job interview.

Suddenly a lot more solutions pop up:

  • You could drive them there
  • They could have a video call
  • They could take the bike
  • They could take the bus

In the conversation you discover that the interview location is just around the corner. They thought it’s much further away. Now that that’s cleared up they decide to walk.

Great. Job interview problem solved and climate crisis averted. Well, not really, but it still helps.

In face-to-face conversations this kind of dialog often happens naturally. Unfortunately, software projects have to deal with different circumstances.

Communication barriers

On reason this kind of dialog often doesn’t happen are barriers. Consider a typical company setup:

  • A team providing product support to customers
  • Another team responsible for customer relations
  • Another team managing the product
  • Another team building the product

And information lost at every step.

Way back in school one of my teachers did a little experiment with us: All but one had to leave the class room. The teacher then told the single remaining student a story. Afterwards another student entered the room. The student who initially stayed had to re-tell the story. This repeated until all students were back in the class room.

The story told to the last student hardly resembled the initial story. In German we call this Stille Post.

Tear down

Some ideas to mitigate this problem:

  • Create product teams where one team covers the whole range of functions
  • Record interviews with customers (if they allow it), and share them
  • Have people from the product building team occasionally join in on calls with customers

More problems

Tearing down barriers helps, but sometimes they cause new problems.

Consider another type of project: An open source project with a public issue tracker for bug reports and feature requests. The users can get into direct contact with the maintainers. No barriers. Everyone is happy. The End.

Unfortunately, it seems as if the more technical the users are, the more inclined they’re to skip explaining the problem. If they’re experts too, they know how to solve stuff. They already identified the problem and did the hard work of coming up with the best solution.

In one of my projects the issue template had a section called “Ideas or possible solutions‟. People ended up sharing code snippets of a possible implementation until I added a clarification that I’m not interested in implementation details. I wanted to know how they’d use or interact with a feature.

I’m don’t know why this happens. Maybe it’s a case of the Dunning–Kruger effect. Maybe it isn’t and the person requesting the feature does have the competency to identify the best solution and even implement it. Even if they do, it helps to communicate the problem. It makes it easier for the maintainers to decide if they want to include the proposed feature. On that note. If you do skip the ask-for-feature step, and submit a pull-request, the same applies: Make sure to explain the problem in the commit or pull-request description. A finished solution doesn’t implicitly explain the problem it’s supposed to solve.

Long story short, here’s my plea: Don’t hold back information. That also means don’t go the other extreme and withhold the solutions you’ve thought of. They help verify that the problem is well understood.

Tip: If you ask for a feature in a volunteer driven open source project, one of the best ways to get it, is to try and convince maintainers that they want it. Stating the problem helps with that.

Conclusion

A Problem Well-Defined is a Problem Half-Solved