Top-down vs Bottom-up Design

Good engineering has a balance between top-down and bottom-up design, but there should generally be a bias towards top-down because your ultimate goal is to meet the system requirements which flow in at the top level.

Bottom-up engineering is important to answer questions of technical feasibility or organisational capability, and ensure that the high level design decisions don't impose burdensome constraints on lower level components. But too much bottom-up engineering can lead to missed requirements and the classic “integration problems” that occur when engineers realise too late in the process that the subcomponents aren't going to work together efficiently at the system level. While requirements flow down the system hierarchy, the balancing force is feasibility which flows back up to ensure that higher level design decisions don't result in downstream requirements which are excessively difficult or impossible to meet.

Including an experienced engineer on the design review team is often a more cost-effective way of answering questions of feasibility than bottom-up activities such as building a prototype or building an experimental ASIC. Engineers generally enjoy building things along the way during a large project, but bear in mind that the ultimate project goal is the final deliverables; all the throw-away prototypes and design revisions constructed along the way are simply steps towards that goal. What counts is what the end customer gets. Multiple ASIC tape-outs, PCB revisions and software releases can simply point to an inefficient development process. Each of these has a cost associated with it, and only the final ASIC, PCB or software release actually gets delivered to the customer. Including design reviews in the process helps reduce the number of design iterations, prototypes and rework required to meet the end goal.

This diagram shows how requirement flow-down is balanced by feasibility in a system design:

Richard Feynman's Appendix to the Rogers Commission Report on the Space Shuttle Challenger Accident criticises the design of the Space Shuttle main engines for being done top-down, suggesting that problems would be easier to find and fix had they been designed bottom-up. His main complaints are about high level design decisions being made without a proper understanding of the lower level constraints such as material properties, and a management culture which dismissed evidence of problems such as components that were operating outside their intended design parameters because the results hadn't previously proved catastrophic. A thorough understanding of the constraints on how things work at the lower levels, and what is going wrong when they aren't working as designed, is an integral part of what I mean by “feasibility” flowing back up to influence higher level design decisions. I highly recommend Feynman's book “What do you care what other people think? Further adventures of a curious character” which talks about his experience on the Rogers Commission and the need to understand what is really going on in complex systems.

As always, balance is important. Nobody designs systems in a purely top-down nor a purely bottom-up manner; finding the optimal mix for a given project, technology and organisation is what is important.

---

Social Bookmark this page: