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

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

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 :)

Answer 2

Try getting them to read the article with "I wanted to know your thoughts on this article..."

Really, your project managers should know this stuff though.

Answer 3

If your project manager has no programming experience, then you are doomed and should find a new place to work.

If your project manager has no programming experience, and is not willing to leave architectural decisions to someone who has some programming experience, then you are double doomed and you very desperately need to find a new place to work.

Answer 4

there's the time-honored "trying to hit a moving target" analogy

which you could step up to wicked level as

trying to hit a moving taget that changes shape, 
wears disguises, hides in shadows, recruits minions,
and shoots back

Answer 5

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.