A solution problem is an emergent property of a solution. Experienced Software Engineers avoid creating solution-problems, they create simple solutions for the root problem.
A few years back I was working closely with designer and musician Martin J. Thompson. We found it difficult to get non-technical individuals to provide the right information about the problem they were facing. So we coined a phrase “don’t give us your solution-problem, give us your problem-problem.” We never actually said this to a client, but maybe we should have.
Stakeholders tend to want to solve problems. It is only natural as human beings, especially entrepreneurs, love solving problems. The problem with not communicating the root problem across to Software Engineers, which you work in close collaboration with, is that it is unlikely that you can see the entire solution space.
The building blocks
As Software Engineers we see building blocks that we can use, all around us. Some we use often, some we use infrequently, but the one thing in common is that most don’t show up in the end product in any meaningful way.
The problem with these building blocks is that they only allow you to build solutions in certain ways. For example if a client said I think we could build this skyscraper entirely with wood, the architect would laugh.
When customers specifically ask for things such as Web 2.0, AJAX, REST, or Java without understanding what problems they are useful for solving we can, and we should ignore those requirements until we are aware that it is suitable.
Think of these demands as being the equivalent of saying to a carpenter that she must use saws and chisels. These are tools and materials, and we are the experts. It is our job to advise on what is the most appropriate.
Understanding the business
The second thing we see are systems of people, people who follow processes. To elaborate a little Bob’s job might require him to prepare 50 spreadsheets per week manually. After Bob has finished these spreadsheets, he sends them to Jane, who, then sends to Lisa a shortlist of those spreadsheets.
Lisa is responsible for ensuring another department is kept up to date. However, this other department needs to use a program only available on a 30-year-old mainframe, so she prints them off and gets Joe to input the data manually.
This process may seem like a perfectly reasonable one to the people involved. Bob’s managers are getting the impression that this is not the case, but they are not quite aware of all the details.
So managers get together and decide that Bob should be responsible for the delivery of some modernisation, he is seemingly the reasonable choice for the business analyst as he produces the spreadsheets. They hire some software engineers and make Bob responsible for giving them requirements.
The trouble is, Bob does not know that Joe exists. He is aware that the system Lisa needs to get the data in is old, but has never seen it.
When the software engineers speak to Lisa, she is very busy and just informs them that she wants to continue receiving that spreadsheet.
When they talk to Jane, she explains in detail how she creates the shortlists, and tells them that she wants an Excel macro built for her. The software engineers are left thinking that perhaps this is a good place to start. Similarly, Bob is looking for a promotion from successful delivery of this automation project and does not want to be manually creating spreadsheets anymore.
It is tempting to deliver all of these people what they want. Seems complex right? UIs need well thought out UX. That is many spreadsheets that need emailing; perhaps that can be automated?
There is lots of room for human error in the entire process. As Software Engineers, we can have a larger solution space.
If the software engineers were able to get access to Joe, they might begin to ask lots of valuable technical feasibility questions: Can we emulate that mainframe on a modern computer? Is it worth the effort right now? Maybe we could emulate a keyboard? Does Jane need to be involved? Does Lisa use the spreadsheet for anything herself?
The result could be to automate away this entire flow and have it running entirely on Amazon Web Services with no manual human input required.
Without fully understanding the root problems, Software Engineers are unable to implement economic, long-lasting, valuable software solutions. When presented with a solution-problem it is important that software professionals dig beneath the surface and ensure they understand where their solution fits into the business environment.