Defining the Neighborhood of a Problem

There is a mathematical idea when you are considering a point in space. Next to that point there is a “neighborhood” of space that is near it. You could think of any spot in front of you, maybe the tip of your nose. The neighborhood of that spot will include some space around that point. Maybe the rest of your nose and a bit of the air around it.

It’s been a long time since I took my last class that relied on a neighborhood. But in several of my posts I have touched on the concept. I will present a problem and then expand into what I think of as other close-but-different problems compared to the original. And that is a key part of the definition of a neighborhood. It requires you to define “how far” you’re willing to go from the point in question. When looking at the entire state of Colorado, the neighborhood of the tip of my nose might be everything in a 5 mile radius. If I’m trying to put sun block on the tip of my nose, the radius will be quite a bit smaller.

So, the mathematical idea of a “neighborhood” can be flexible to the context, but it gives a terminology for talking about the set of things that are close to some specific thing. And more than that, it gives us a framework for defining what “close” means. How does this apply to problem solving?

I have written more than a couple of times about the idea of negotiating requirements with your stakeholders. I also implied that you should be judicious about how you handle that negotiation. When I started writing on the topic of avoiding type 3 errors in 2013 (i.e., solving the wrong problem), there was not a ton out there. At this point, it’s virtually a cliché. In fact, I got so frustrated after a conference this year that I wrote and gave a presentation on how to continuously confirm you’re solving the right problem. What I heard at the conference mostly seemed to be just paying lip service to the idea of “yes, make sure you check that box before you start coding!”

Negotiating requirements is fundamentally about defining that neighborhood of problems which are close to the stated one. The best way I know how to explain the neighborhood of a problem is to consider the problem, and then “tweak” one or more of the inputs / assumptions / desired outcomes / etc. If x is the requirement, is 0.9*x close enough? If it’s not, how about 0.99*x? If the requirement was written as pass-or-fail, can we rewrite it as a continuum instead?

But, getting back to the point, why would it make sense to negotiate the requirements at all? What value do we get from exploring the neighborhood of a problem statement? In optimization the neighborhood is useful because you can use it to understand if the current solution is the best nearby one. For certain kinds of problems, all you need to know is that the current solution is better than everything else in the neighborhood, and then it is the best overall.

Carrying that description over to the neighborhood of a problem statement, we learn a couple things. First, practically speaking, when you try to negotiate a requirement with a stakeholder, you learn a lot about their priorities. Mathematically speaking you learn if the current problem is similar to the neighboring ones. If your stakeholder says their requirements are x, but they are fine with .5x as well, it makes sense to say that the neighborhood of similar problems is larger than if they insisted on .99x.

The notion of exploring the problem space can be useful. At the same time, it is an abstract idea. When someone tells me a problem and their requirements, I try to identify which ones might be flexible. I also look for which requirements, if changed, might allow the problem to achieve a solution I think will be better overall. In principle, every requirement we loosen makes the problem easier to solve. And as long as there are tradeoffs between outcomes and effort, most problems will have some similar problem in the neighborhood which is better.