Top-down versus bottom-up design approaches

Technique · Chapter 5

The two approaches

Top-down: start at the highest abstraction (the whole system) and decompose downward, adding detail iteratively until you reach the component level. Component internals aren’t part of the architecture, but their public interfaces are (they let you reason about interactions). Best when the domain is well understood; favored by enterprises because the planned method aids time/budget estimates. Strict top-down (heavy up-front design) has become less common.
Bottom-up: start with the components the solution needs and compose upward into larger structures, like building blocks, until requirements are met. No up-front architecture — the architecture emerges (a.k.a. emergent design / emergent architecture). Doesn’t require a well-understood domain, since the team tackles one small piece at a time and learns as it goes.

Top-down: pros and cons

Advantages

Systematic; breaks the system into smaller parts that lend themselves to dividing work across teams and creating individual tasks.
Supports task assignment, scheduling, and budgeting — attractive to enterprise management, and useful when you’re asked to help with estimates.
Works on small and large projects; especially useful for large ones.

Disadvantages

Risk of big design up front (BDUF / BUFD) — design flaws or missing functionality may surface only later, when changes are costly.
Only works well when the domain is well understood — often it isn’t.
Multi-team setups make knowledge sharing and reuse harder; the architect may have to spot and abstract reuse and encourage collaboration.
Temptation to become an ivory tower architect — hand off lower-level design and disengage. Stay involved so later changes are easier.

Bottom-up: pros and cons

Advantages

Greater simplicity — build only what the current iteration needs.
Fits agile: each iteration ends with working software; refactoring, automated unit testing, and continuous integration raise quality.
Avoids BDUF and over-design (some in the agile community favor no design up front / NDUF).
Coding and testing start early, so feedback (and needed changes) come sooner.
Facilitates code reuse, since focus stays on a small set of components.

Disadvantages

Assumes change is cheap — but refactoring the architecture can be very costly.
No initial architecture can lower maintainability if the team isn’t diligent.
Full scope may be unknown, making project-wide planning/estimation hard — often unacceptable for enterprise software.
Not immune to late-surfacing design flaws either.

Which to use?

Lean top-down when more than one is true: project is large, complex, enterprise software, large/multiple teams, well-understood domain. Lean bottom-up for the opposite: small, simple, non-enterprise, single small team, poorly-understood domain.

A hybrid usually wins. Extremes (full BDUF or no design at all) are rarely ideal. Do enough top-down work to establish a high-level structure (useful for organizing teams and informing project management), then switch to bottom-up to design and implement components. The real skill is judging how much up-front design is appropriate — and no single approach fits every situation. Approach choice alone doesn’t guarantee quality; correct design decisions still must be made.

Citations

Software Architect’s Handbook (Packt, 2018), Ch.5 “Top-down versus bottom-up design approaches”, pp. 279-287.