What's a good analogy to explain the concept of wicked problems? [closed]

Question

Most developers understand the concept of wicked problems. What's a good analogy to use when explaining this concept to project managers?

Answer 1

If you want an analogy, I would go with the timeline of NASA. Still technical based, but you do not need any coding skills to understand the difficulty involved. I'm also using the Coding Horror definition of a wicked problemm in that:

Horst Rittel and Melvin Webber defined a "wicked" problem as one that could be clearly defined only by solving it, or by solving part of it. This paradox implies, essentially, that you have to "solve" the problem once in order to clearly define it and then solve it again to create a solution that works.

When NASA started, they were tasked with getting a man on the moon. I'm sure at the time they had ideas of how they were going to accomplish the task, but there was no way they could spec out the first moon mission at the start. They had to develop rockets and find out all the catastrophic things that could go wrong. They had to get an orbiter flying around the Earth and then bring the astronaut back home safely. Eventually they got to the point of getting to the moon, but there was still the issue of getting home.

I hope this seems like a non-programming wicked problem to your project manager. If not, I agree with Glomek. You are doomed.

Answer 2

Every changing requirements lead to an impossible to manage design. Just send him here: Winchester Mystery House. The house is filled with staircases to nowhere and doors that open to brick walls. It was built exactly as spec'd, but isn't really what you'd call usable.

Of course up here in New England a "wicked problem" is one that requires a wicked good engineer to come up with a wicked clever solution :)