I would add [referring to Mitchell, 27 Jan 97] that all design methods are simply paper descriptions of procedures that humans are meant to execute. At least in design, machines can't execute these, and that means that people are adding something important. In other words, such design methods are substantially incomplete.
A good way of thinking about them is that at most they emphasize one side of the design method; it may well be that different methods emphasize two aspects both of which are important, and both of which are in fact necessary. This shows up if you observe real practitioners. While bad designers produce poor designs no matter what "method" they use, good designers can often be spotted adding silently (even unconsciously) aspects of the method two, so advocates of method two can say that is why they succeed even though they say they are using method one. (What those advocates may miss is that they have to add aspects of method one to their own practice if and when they produce good designs themselves.) So I agree with Bill in a big way. We have to read paper design methods (which is all that software engineering, for instance, consists of) as explicating a partial truth, and should be valued for that partial truth; but it is not relevant to criticize them for omitting important things--all design methods do.
(Of course as theories, all such methods are pathetically incomplete; but then they are useful, which theories in education have trouble being.)
[An example, though not necessarily an interesting one, is the issue of cost-effectiveness and keeping within budget that we discussed a while ago. Most design methods do not mention this, but take it for granted that their practitioners will do this "outside" the method as written down.]