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. This process has been motherhood and apple pie in software development for decades**. (Steve McConnell)
A computer industry adage is that Microsoft does not make a successful product until version 3. Its Windows operating system was not a big success until the third version was introduced in 1990 and, similarly, its Internet Explorer browsing software was lackluster until the third version. (Seattle Post-Intelligencer)
As far as I'm concerned, all software development can be classified as a Wicked Problem. It's far too complex and far too annoyingly micro-complicated to allow for a whole lot of rational planning. I know from personal experience that I can never get very far without writing code to better understand the problem I am trying to solve.
I'm not proposing that we all revert to a "code like hell" methodology. But I think it's incredibly foolish to believe any team of developers, however talented, can plan out an entire project from start to end, forseeing all the contingencies, emergent problems, and weird-ass edge conditions they're bound to run into. It's thinking like this that leads to classic waterfall project catastrophies. Too much up-front planning is counterproductive and potentially disastrous.
Instead, I believe you have to continuously code throughout the lifecycle of a project and constantly integrate that development feedback into your planning. The sooner you've attempted to solve the problem, the sooner you will have a handle on the problem. I'd even go this far: if you're not writing code for more than two days at a time, you are putting your project at risk. But you have to write the right kind of code at the right time:
There are a lot of different methodologies that cover the same ground. Some people call this Agile Development, XP, or SCRUM. All of these fancy buzzwords have a common ancestor: the classic book Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms.
The comments to this entry are closed.