Problem Solving
A puzzle is a problem we usually cannot solve because we make an incorrect assumption or self-imposed constraint that precludes a solution
Similar to the XY Problem and my favorite question, “What are you really trying to do here?”, when you get stuck on a problem, make sure you understand the space you’re working in.
In development those constraints often come from the existing systems. The data structures and flow that are in use to solve the problem as it was understood last week. They were appropriate then, and we used them to solve that problem.
But this week we know more. And might understand the problem differently. But our first instincts are to treat all of the previous work as constraints on solving today’s problem. That’s a good place to start. After all, it worked so far. And it will likely work again.
Unless our new understanding of the problem has changed the underlying assumptions enough so that the constraints we’ve built for ourselves have become part of the problem. Maybe even the biggest part of the problem. Then you need to take another look at your assumptions and make sure they’re not holding you back.
Consider a workflow system. At first, getting things working and making the work flow is the problem and you can relegate problems and issues to some kind of exception handling. As the system matures and workload increases you continue to make things more robust. Smoother running. The percentage of issues goes down. But the raw number of issues goes up.
Until at some point the sheer number of issues, no matter how rare, becomes an issue itself. You reach a point where you can’t solve the problem by making them even rarer. Your problem space has changed. Your system has changed from a workflow system to an error handling system. The workflows keep happening, but instead of focusing time and effort on making them happen, now you need to focus on handling errors.
Which means the assumption that you can ignore errors is now incorrect and the place you’ve been stashing them for later is now a constraint. When you need to solve the current problem you need to revisit those constraints. You need to remove them from the problem solving at least, and probably from the system as well. And that’s OK. The code works for us, we don’t work for the code. If it needs to change then change it. Solving the problem, adding value, is the goal, not working within the existing constraints.
That doesn’t mean you should throw everything out and start again. That (almost) never works. You need to find the balance. And finding balance starts with knowing which of your assumptions and constraints are real, and which are just there because they’re comfortable.
