BigDesign is not monolithic, but there ''are'' many points such methods have in common.  

Here are some major objections to BigDesign, both theoretical and practical.


'''In Theory'''

1) BigDesign advocates lots of thought up front, on the grounds that this will produce lots of knowledge up front.  BigDesign critics point out that thought and knowledge are just not the same thing.  Knowledge may be initiated by thought, but is actually just codification of empirical experience.  Throwing away the free-wheeling flexibility of the cowboy in response to the stunning failures created by no thinking at all, is throwing the baby out with the bath water.  Cowboy's at least have empirical data with which to reason.

Because software is complex, there is a limit to how much of it a designer can work out in her head.  Critics maintain that the limit is actually rather low.  A hundred UML diagrams are almost certain to be wrong somewhere, and often in dramatic and unbearable ways.  Failures in UML diagrams demonstrate the opposition between thought and empirical knowledge.

2) BigDesign sees any uncertainty as a danger. The idea is that by eliminating all uncertainty in our vision, we are providing the fodder for the planning process and seemingly guaranteeing its success.

Critics respond:  there is no way to eliminate uncertainty in the absence of actual empirical results.  Furthermore, some efforts to eliminate uncertainty may actually ''damage'' our results.  See AjiKeshi for a metaphorical discussion.

'''In Practice'''

The very weight of the many formal mechanisms, structures, and processes that are utilized in BigDesign methods contributes to their failure.  In fact, people do ''not'' follow BigDesign procedures with any great regularity, even though they often begin with them.  BigDesign seems, in practice, insufficiently flexible in responding to the challenges presented by modern development.  Rapid turnaround of revision, wildly varying customer requirements in response to markets, super wildly varying quality of development team, and so on, each serve to present major obstacles to the kinds of heavyweight analysis and design advocated by BigDesign.

If we criticize BigDesign, and we criticize CowboyCoding, then where are we to go?  One option:  ExtremeProgramming.  For a detailed look at XP, try ExtremeProgrammingRoadmap.  The preceding notes derive mostly from an Xp perspective, which is a very important point that people who are pro BigDesign need to remember.  Xp is not CowboyCoding.  We are not your historical opponent, we are your new one.
----
I tell the following story from a perspective of surprise:  I ran into a BigDesignUpFront project, speed-critical COBOL / non-relational database banking system.  The group obviously had been working on this general, but not specific, technology for dozens of years, were ISO9000 certified with their BigDesignUpFront, strictly waterfall process.  They had worked for months on a particular design, elaborating the structured analysis charts or structured design charts, when they discovered that the design really would be unmaintainably ugly and slow.  So they started over, from the top, back in February, bidding a late August completion date for their 35 programmers.  I predicted failure, doom, gloom, catastrophe, delay, etc.  I got word in early September that they had delivered.  uh.  now what do I think?  --AlistairCockburn