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 (1973).  The 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.  This process has been motherhood and apple pie in software development for decades (Peters and Tripp 1976) … a dramatic example of such a wicked problem was the design of the original Tacoma Narrows bridge … This is a good example of a wicked problem because, until the bridge collapsed, its engineers didn’t know that aerodynamics needed to be considered to such an extent.  Only by building the bridge (solving the problem) could they learn about the additional consideration in the problem that allowed them to build another bridge that still stands.
Code Complete Second Edition - Steve McConnell (Chapter 5.1 Design Challenges)

Perhaps because I am a Mainer I keyed in on this content.  It’s wicked good!  At any rate, I like the example that McConnell uses to illustrate a wicked problem.  Imagine though that the bridge had not collapsed, and instead only violently swayed in the wind.  Would the engineers have taken down the bridge and started over, or would they have monkey patched tried to extend a flawed design?  Would the bridge have been easy to “fix”, or would the fixes only have introduced more potential for disaster.  It’s interesting to think of software in this regard.  It’s impossible to design software today that addresses every issue of tomorrow.  If the software is written in a cohesive, organized, thoughtful way though, it should be easier to monkey patch extend.