§ 110
Wicked Problems
For some problems, working out what the problem is and choosing a solution are the same act, so the requirements cannot be settled before the design starts and there is no point at which the problem is done.
Keep in mind
When solving changes the problem, treat its statement as a draft, not a gate
What to do
Before writing requirements, ask two questions: does the problem statement change every time someone proposes a solution, and is there no test that would say it is solved? If both are yes, stop trying to freeze the requirements first: put the people who disagree in the same review, show small versions early, and decide in advance when you will stop, since the problem will not tell you. If either is no, treat it as tame and write the problem statement.
Why it happens
Rittel and Webber contrasted "tame" problems, such as solving an equation or checkmate in five moves, where the mission is clear and so is whether it has been solved, with "wicked" ones, which include nearly all public policy issues. For a wicked problem, "The information needed to understand the problem depends upon one's idea for solving it", so "The formulation of a wicked problem is the problem!" Phased methods that start with "understand the problems or the mission" assume you can understand first and solve afterwards; for wicked problems "one cannot first understand, then solve." And "Wicked problems have no stopping rule": work ends because the planner runs out of time, or money, or patience, not because the problem says it is finished. Product and organisational questions with many stakeholders can behave this way, with each proposal changing what people say they want.
When it stops applying
Understand the Problem First: Pólya's method opens with "You have to understand the problem." and asks "What is the unknown?" before any plan is made; for much engineering work, such as a bug, a migration or a latency target, writing down the unknown, the data and the condition first is what makes it solvable, and calling such work "wicked" excuses skipping that step.
Source
Horst W. J. Rittel & Melvin M. Webber, "Dilemmas in a General Theory of Planning", Policy Sciences 4 (1973), 155–169 — the tame/wicked distinction and the ten properties of wicked problems. George Pólya, How to Solve It (Princeton University Press, 1945) — the counter, understanding the problem before devising a plan.
Read the sourceCite this
Hammurabi, § 110, “Wicked Problems.” https://kanywst.github.io/hammurabi/laws/wicked-problems/
BibTeX
@misc{hammurabi-wicked-problems,
title = {Wicked Problems},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 110},
url = {https://kanywst.github.io/hammurabi/laws/wicked-problems/}
}Read in a column
- Deciding what to build Next in the column: Working Backwards
Related laws
- 10XY ProblemPeople ask for help with their attempted fix instead of the problem they actually have.
- 75Working BackwardsTeams that start from a solution often build things no customer needed; starting from the announcement exposes that early.
- 111Most Ideas FailIn online controlled experiments at large web companies, most ideas that survived the team's own pruning do nothing or make things worse once they are measured, and experts tend to be poor at telling in advance which ones.