Proving Top Down Design Harmful

Consider a company whose upper management is considering the establishment of a systems engineering group to be the point for project requirements and architecture. This scares for several reasons. But one of the major reasons in the slide presentation we were told classical SystemsEngineering uses a TopDown approach.

It was countered that TopDown is not sufficiently powerful to create a complicated system because every layer of design and implementation informs every other layer. It's not possible to sit from the top and design everything because no matter how smart you are YouAreNotSmartEnough?. So, is there some sort of generic proof of the inherent power of TopDownDesign vs whatever else?

Proving conclusions about a process strikes me as very difficult, if not impossible. You could form an econometric model of the various processes in question making sure to include things like

transaction costs,
stochastic variation among consequences,
likelihoods & opportunities for detecting errors, and
expected signal degradation among communication channels

Then plug in assumptions about each factor, after picking some DiscountRate? out of thin air, and see which one yields a higher NetPresentValue. All this seems to me to be an incredible amount of work for almost no gain. If your management only responds to formal proofs or mathematical models, start looking for another place to work. It seems to me that they'll be DeerInTheHeadlights? under any real-life business situation. -- MarkAddleman

Would you build a building from the top down?

No. But I'd design one from the outside in - big pictures and big ideas towards the little details.

(but) -- ProofByAnalogyIsFraud?

It's not even a good analogy, since it equivocates the word "top down" between "fully planned before begun" and "physically constructed from highest elevation to lowest". By the first definition, virtually all buildings are indeed the result of "top-down" design.

Ahhh - but TopDownDesign doesn't really mean "fully planned before begun" - it means "start at the big picture and work toward the details", a form of stepwise-refinement. Buildings are built from the bottom up, and to some degree they are designed from the bottom up. Good software is designed from the bottom up, top down, inside out, and outside in, all simultaneously - but good construction, physical or virtual, is usually bottom up. I think the analogy is a good one.

Construction ain't design.

I favor LeftRightDesign?. The idea is to build one module, probably the simplest, to document the primary architecture, then fill in until the whole thing is ready. All components after the first can see both the bottom and the top because it's already been done in the rough.

I suggest doing the hardest module first. The simplest one does not test the limits of the architecture.