Solutions are Meaningless

Problems are invaluable

“Hey, can you make that button red?” — Co-worker before he/she darts out the door.

This is a very common event in the day in the life of a developer. A quickly worded request is dropped off and left to be implemented or understood.

There is a very real risk in following such strict instructions. The instructions were dropped off without context or preamble. There is no apparent strategy or goal associated with it. This is a clear indication that this is a solution and not a problem.

Solutions are meaningless without the context of a problem. Instructions such as “hold your breath” and “scare yourself” don’t make sense until the one receiving said instruction is made aware that the solutions are intended to cure hiccups.

It is the nature of human beings to really fall in love with their own solutions. Particularly solutions that have been hard won by experience and adversity. “When I was going through [insert situation here], I really felt like [insert solution here] worked for me.”

Indeed, solutions can be beautiful things. But, solutions are rarely one size fits all.

Let’s ask a bunch of questions

When given a solution instead try to refocus the discussion on the problem. Who is affected by the problem? What are they intending or not intending to do? What is really happening? What are the business goals in this matter?

As a developer, problems are much more important to understand and talk about. Describing and exploring a problem lays out the groundwork of understanding where the obstacles in a task lie.

As these questions are answered, the potential paths for the solution start getting organically trimmed down by the nature of the task. You may discover that the red button suggestion is really an attempt to try to solve the problem of drawing the customer’s attention to a particular action. That area of exploration may then bring up the business goal of selling X widgets by the end of February. Armed with this new information the discussion can then explore questions of how promotions are currently done, their success rate and whether that strategy applies to this problem.

Ok, you just made a small request into a mountain of work

These questions seem like a lot of up front work, but in the long run it can save a lot of time and effort. The process of detailing out the problem gives the developer a goal or position in which to hang and interpret the results

When that goal or position is no longer relevant then the resultant change also becomes irrelevant. For example, If the red button is implemented due to customer sales for February, the button change could potentially be dropped or reverted in March.

Additionally, when a future change is implemented that conflicts with the results of the current problem, documentation of the problem will give the future developers access to the how and why of the problem. This will give them the context to decide whether they need to retain or drop a previous solution that is conflicting with their current work.

If documentation only contains, “Change the button to red. xoxoxo -Co-worker,” future changes are now impeded in the process of detangling whether the change is something they should respect or ignore. This can result in future implementations that are less effective because it unnecessarily tries to accommodate an older solution or worse, it is error prone due to removal of code that still served a purpose.

Often documentation only contains the actions performed, that is, the solution. The why needs to be documented as well or risk being lost to time and turnover.

Verification

Working with the problem provides the ability to apply good metrics. If the provided solution is to turn the button red, then when the button is turned red, the developer is left with the understanding that they have completed their task to the best of their understanding.

However, this may not satisfy the individual asking for the solution. They may wonder why sales figures haven’t gone up with the implemented red button change and soon a new round of solutions and implementations are started. This is a wasteful process that leaves the developer holding the bag for a situation in which they do not have full understanding.

If a problem is presented then explored, the main objective can be discussed and more accurate metrics can be determined. These metrics can then be measured against the implementation. This allows the developer to meet a goal even if the discovered solution isn’t the same as the prescribed one.

Perhaps, instead of a button color change, the content of the button or the size is altered. If the developer can provide evidence that supports that such changes increased traffic to the intended areas then you have a verification of the implemented solution.

Shouldn’t those developers just do what they are told?

There is the supposition that if a feature is requested that the development staff should do their best to make that feature happen without question. Indeed, some workplaces embrace this idea.

There is an inherent flaw with that process however. The sphere of development is a combination of complicated disciplines spanning categories such as user experience and disability assistance to more technical details such as cross system communications and data storage. Without input from a member of the development team, it can be difficult to plan a working solution that is feasible, sustainable and optimized to the end user. These areas of expertise are after all, what they were hired to do.

This doesn’t preclude discussions before the problem is presented to the development team. Indeed, the questions of intended consequences and audience are ones that need to be addressed or at least outlined before implementation is even considered. In some instances whole problems can be defined and solutioned before it gets into the developer’s hands. However, the problem should be submitted with the proposed solution. Without it, the developer is left to either search for the problem to get guidance on the inevitable missing pieces or to “wing it” and fill in the details as they see fit.

So, what are we trying to accomplish here?

Proposed solutions are often put forward for implementations without the respective problems and they hinder efforts to accomplish the goal of solving the problem.

Developers, and other members of the organization, need to start any feature or bug fix process by asking “What are we trying to accomplish here?” Organizations that learn to do this will find that they spend less time iterating on low impact objectives while being more aware of obstacles and issues.