OK, let me clarify. Engineering is not 100% about problems. It’s more like the first 70% or so. The last 30% is about the solution.
In all of the engineering teams I’ve worked in, I’m convinced that one of the biggest productivity killers is lost time due to engineers not fully understanding the problem they are trying to solve. Conflicting advice, not understanding all of the constraints, unclear expectations leading to the need for re-work and ultimately frustration – these often all have the same root cause.
The cause is that we start focusing on the solution before we understand the problem.
It’s in our nature as engineers to start thinking about how to solve a problem as soon as we see or hear about one. After all, we decided to become professional problem-solvers. Years of working in the area of development tools has meant that I often find myself listening to an engineer present a solution they want to see implemented, leaving me to dig in order to understand the problem he wants solved. We tend to think in terms of solutions … and so before taking the time to fully understand the problem, we are already thinking about the solution.
It’s easy to see why we do this: the solution is the fun part. It’s where we get to be creative, where we get to learn new technologies, try new things, fail, get up, and try again. It’s like solving a gigantic puzzle or playing one gigantic game of chess.
Except that solving the problem before we actually understand the problem can be like playing chess without understanding the rules. Time gets wasted with developers not understanding what it is they actually need to do, re-work needs to be done, and the entire solution often takes much longer to finish.
If you want to solve a problem, make sure to define the problem first. What are all of the use cases that need to be solved? What are the constraints you have to work within? What are your timelines and deliverables? Only after you have a clear definition of the problem is it time to start thinking about the solution.