There are many types of problems in software and we developers love to solve them all. However there exists a class of nefarious problems that all teams must go through and they are no fun at all, welcome to the world of Wicked Problem
A Wicked Problem is defined as a problem that could be clearly defined only by solving it or part of it.
For most problems we first understand the problem then find ways to tract it, Wicked Problems offer no such luxury.
Essentially the only way to solve such a problem is iteratively by first coming up with a tentative solution which helps you define the problem then solve it again to come up with a solution that works.
To know wether you are smack right in the middle of a problem Conklin in his book Dialogue Mapping: Building Shared Understanding of Wicked Problems shares what characterizes a wicked problem:
- The problem is not understood until after the formulation of a solution.
- Wicked problems have no stopping rule.
- Solutions to wicked problems are not right or wrong.
- Every wicked problem is essentially novel and unique.
- Every solution to a wicked problem is a ‘one shot operation.’
- Wicked problems have no given alternative solutions.
In the world of software design, non trivial projects are inherently wicked. This follows from the following facts:
- Requirements are almost certainly guaranteed to change
- Different designers can come up with different designs all of which are correct
- The design process is full of false starts
- There is no way on the onset to know if your chosen design is good enough
- A good design is usually subtly different from a bad one.
While I would wish to conclude this article with nice algorithmic solution to this class of problems, the best advice I can give is when you come across such a problem, iterate and iterate first. It’s far cheaper to correct design mistakes at design stage than when you have a full blown coded project.
Have you dealt with a wicked problem before? How did you handle it?