Understanding Big Design

BigDesignUpFront has taken a lot of stick on this wiki. But many think BigDesign is not stupid. Many fine minds, working for many years on the widest possible range of software problems, have produced big design methods, and only a fool would belittle their powerful and nuanced models without trying them out.

Nevertheless, minimalist methodologists are prepared to offer a critique and in some cases an alternative to big design methods. How can such things be?

Understanding the case against big design requires a fairly thorough exegesis of the case in favor of it. Here are some notes intended to stimulate our understanding of the case for big design.

BigDesign has its historical roots as a response to projects with no design. Cowboy coders, initially the darlings of our budding industry, are the BigDesign villains of choice. And justifiably! CowboyCoding fails. It's as simple as that. Tell that to the Mac team.

Once it became obvious that hiring non-communicative poorly-dressed geniuses was not the way to go, it became equally obvious that we needed a method for software development. Methods are of course the sine qua non of the rationalistic tradition. In our case, creating a method has as straightforward a rationale as you can get: If we have a method, we can a) teach it, and b) improve it, and c) theorize about it, until we d) perfect it.

BigDesign has its philosophical roots embedded in TheRationalisticTradition, a loose cluster of related concepts that underly virtually every success western civilization has ever offered. This tradition is so deeply embedded in our worldview as to be almost invisible to us.

On the other hand, BigDesign often leads to monumental failures. The great pyramid of Khufu is the best known. Hundreds of thousands of people labored a lifetime to achieve immortality for one man. And they failed miserably. The operation was a success but the patient died.

Of course, seen from the perspective of BigDesign, the opposite is also true, the pyramid is demonstrably a success for BigDesign: 5,000 years later, not only is his monument still there, but we even know his name and talk about him, visit his monument, etc.

Um, rationalistic or rationalizing tradition, did you say? Khufu is dead, and only his name lives on. That wasn't his requirement. He didn't say, "look, it's okay if I die so long as a syllable and a bloody great pile of stone survive." He said, "look, I'm the boss, and I'm going to be the boss forever. I don't care what it takes - make it so." Well, it's not so, it never was going to be so, and the only reason why all those hundreds of thousands died for such great foolishness as Khufu's syllable was because of BigDesign.

[My understanding is that the pharaohs built the pyramids in order to provide their souls with a means to properly ascend into the afterworld. Who are we to say that the pyramids failed in this purpose?]

Those who would say the pyramid, and BigDesign in general, is a failure would say it is because it doesn't deliver. Why doesn't it deliver? Because it doesn't prototype, doesn't test, doesn't experiment, doesn't measure, and doesn't architect. It is art, not science, that drives BigDesign. So the results seldom if ever turn out to be what's needed. They may be beautiful, grand, awe-inspiring, mind-boggling results, but, ultimately, they hardly ever solve the intended problem within scope or budget.

Those who would say the pyramid, and BigDesign in general, is a success, would point to the amount of prototyping, measuring and architecting that went into it (and other BigDesign projects). They think that any accomplishment, not the one that is required, will do, so long as it leaves behind BigModels.

Of course, Khufu had an unlimited budget and no-one to contradict him on scope, so as long as the work got done, it was not possible for him to go over scope or budget. Many BigDesignUpFront methodologies are based on the assumption that you have a small number of customers who can be very specific about what they want, and who will then sit by patiently while you build it for them on technology that will remain stable throughout the lifespan of the project.

[Meta: I don't understand why this discussion should not go under the topic BigDesign. "Understanding" is implied in ANY wiki topic, even if it is not actually achieved.]