Customer Reviews

Wicked Problems, Righteous Solutions: A Catolog of Modern Engineering Paradigms

5 star:		(6)
4 star:		(1)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

"Wicked Problems" should be CS undergrad required reading, just as "Zen and the Art of Motorcycle maintenance" should be read by every mechanical engineer. Wicked problems doesn't wonder off into terminology and methodology, instead it teaches meta-methodology thinking, which will be vastly more useful in practical application. Learning the HOW of a design methodology is less critical in a career path than learning the WHY of all methodologies. That such a useful book is written in simple conversational style with great real world examples is a marvel. You want to build complex systems? You need to read this book.

A detailed and well-supported essay on the the "waterfall" method of software development. The author defines a wicked problem and then explains the various leaks in the waterfall method for most software projects. Documented variations are then explained in detail and how they attempt to plug the leaks. Most of these include either spiral, prototyping, iterative, or incremental techniques to enhance one or several of the "classical" steps in the waterfall approach.

Finally several other methods of software development are discussed such as: "video / hollywood", "clean room", "scrum", and "sashimi". Overall the writing style was fluid and very easy to read however the content is somewhat dated when compared to the newer texts on agile methodologies. If you are committed to using the waterfall method or a variant then this book provides sound advice and good references.

This is an excellent overview of what software development processes folks are using, and how they are similar to or different from each other. It has pointers to additional information on each method. Now I can easily recognize what method or partial methods a project is using, and better predict what its weak points are going to be. I only wish I had read this book first.

Authors, please publish an updated version including more recent methods like extreme programming!

The idea that many situations have overlapping problem & solution domains is immensely valuable. Using some of the ideas in other situations, especially with young people, has generated better solutions than I ever imagined possible.

Give a copy to your favorite school teacher or city government official -- with the obvious caveat of course.

This book is a great foundation for those seeking to understand why waterfall methods don't work for this kinds of problems that today's software projects often set out to solve. The book puts waterfall in context with other development approaches. While many of the examples are "dated" this just makes clearer that agile methods are not entirely new and problems they solve were have a lot of historical justification. In addition to all of this, this book had many excellent references that provide historical context and insights in to things you might want to learn more about. This books is a quick read and is a book every programmer and project manager should read at some point in their career.

"Wicked Problems, Righteous Solutions" was published 20 years from the point of this review. Within these 20 years, the book is dated yet also still amazingly up-to-date. Most of its up-to-date information has been summarized in the numerous books about agile and iterative development, yet most of them refer back to this book for more background information.

I guess the essence of the book is that waterfall is a bad idea, there are good reasons for why it is a bad idea and there are alternative (ideas) that are worth considering that prevent that idea.

The first two and the last (9) chapters cover the old discussion about is software development a science, is it engineering, or is it an art? What does being a professional mean in software development. It is amusing how relevant these questions still are in 2011, though the definition of what a craftsman is and does has definitively evolved over the many years.

Chapter 3 and 4 (nearly half of the book) discuss the waterfall method, its history, the variants and also the many reasons why it doesn't and cannot work. One of the main reasons, the authors argue, is that software development is a "wicked problem" which is defined as "you know what system to build only after you build it." In other words, the world changes and both the developers and customers/users of the system constantly learn and therefore you cannot define the whole solution in the beginning but need to actually build something in order to gradually learn. Of course, much of these ideas have been taken years later in the agile development space and new ways of working were created to deal with that (of which there are some origins in this book).

Chapter 5-8 discuss different alternatives to waterfall development. Some of these are realistic and some of these seen more of an idea from the author (or one other person) than reality. Chapter five talks about incremental and spiral development and how that solves some problems with waterfall development. Chapter six discusses combining and replacing waterfall with prototyping. Chapter seven discusses the models that are now more the "agile" models where development moves away from phases and tries to do all activities at ones. Chapter eight covers a couple of rather exotic ideas which I never heard of before and will probably never hear of again :)

All in all, the book was an easy read (even though it took me nearly 10 years to finish it, reading it one little bit at the time). Though, to be frank the first couple of chapters were most interesting (that is the argument against waterfall development) whereas the alternatives felt a bit weak. It almost felt like the authors just wanted to write a negative book about waterfall development and the reviewers said "hey, you need to write some alternatives" so they wrote some alternative ideas. The alternatives don't provide enough information to actually implement them, whereas the anti-waterfall parts definitively consider enough information to convince nearly everyone that waterfall development actually doesn't make much sense. For me, it is this negativeness that the book has and its bit too exotic alternatives ("Hollywood model?") that made me rate if 4 stars while I was even considering 3 stars. Yet, for anyone who needs a good argument against waterfall or anyone interested in some of the influences of modern agile development, this book is recommended.

As a software engineer, our profession is often faced with tackling business problems that are unique and do not fit with a particular way to solve the problem. This book points out that very point and explores the solution domain for these problems. Supposedly in software development, we can take any problem, apply the waterfall lifecycle and live happily ever after. Well, as we all know, the waterfall often gives us problems in particular application domains. Great book.

Want an analysis of software engineering techniques that will make you think? Want a text that is well written, organized, and contains more that than ususal fluff of these types of texts? Then get this book. (Go to the library and check it out!

I think this book has a point that another book doesn't have. But, simply put, I feel difficult to understand the point.

Unfortunately, this book is too old. The examples that the authors show seems rather unfamiliar for me. I don't know about COBOL or Fortran. As well, I don't know theories or situations at that time when the book was published. Hence, I don't understand those and those problems.