In my role as a software engineer I am constantly presented with problems and as engineers we try to come up with a solution immediately. It’s almost like a reflex. In these situations, a lot of times we take the problem for granted and accept the context, constraints of the problem. However, over the past couple of years I have really learned to value designing the problem first. Sometimes this means dismissing the obvious and exploring the consequences, as Russell Ackoff would describe it.
Below are the two most common ways I am approached by others in engineering the tools that will eventually be used by people to accomplish their work.
When approached by project managers for example, sometimes the conversation will start with a problem the customer is having and it will be up to me how to solve it. For example, “The customer is saying they need a way to search for these specific types of incidents in their system.” The solution could be adding a search field to an existing screen or adding a new screen dedicated entirely to this scenario. This is approaching the problem from a literal view and starting my process of engineering a solution in a very direct response type of way. In the business of delivering custom line-of-business applications there is usually very little work done by a designer, so it is more Customer > Project Manager > Engineer. Sometimes there is more value in taking a step back and not jumping straight in to coming up with solutions, even if your role as an engineer is to eventually implement a solution.
Sometimes the problem is described and the other person prescribes a solution. For example, the project manager will describe a customer problem of needing to track addresses within our system. Then it might be described that the software needs to have a web page added that allows users to type in an address, Line 1, Line 2, City, State and so on. Presumably, this means the person prescribing the solution has already taken the time to analyze everything and synthesize what would be most useful. Sometimes this is legitimate, if this work has actually been done. The software engineer does not have to be the role that designs the problem and solution. In the most literal sense, the software engineer is responsible for implementing the solution.
If you find yourself as an engineer either accepting problems as-is or accepting problems and their prescribed solutions, even if another role like a project manager is going through the work of crafting the problem and solution, then I challenge you to question the other role and test if they really have designed the problem and solution. In a lot of cases, the decision to go with a specific problem/solution pair is based on time, effort and other tradeoffs. These are different for each person.
Delivering the right software is not always the result of matching a solution to every problem. Sometimes, changing the problem is the key to delivering the right software.