Design Is a Wicked Problem
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.
Tags: Quotes
July 22nd, 2008 at 4:34 pm
Awesome analogie Jason. I know the Tachoma Narrows Bridge very well since I teach about it in class, but I never related it to software, nor was I aware of the Wicked problem. I am not sure Microsoft has learned everything they could from past experience.
July 22nd, 2008 at 7:25 pm
Thanks for stopping by Mike, and I’m glad you appreciated the analogy. Code complete (from where the analogy is derived) is full of useful analogies such as this one.