Definition
Top-down design is the strategy of solving a problem by first describing its highest-level structure as a sequence of named pieces, then independently decomposing each piece into smaller pieces, and continuing until the leaf operations are simple enough to write directly. The technique pushes the designer to specify what before how — to commit to an outline of intent before being seduced by the details of any single component.
The complementary strategy is bottom-up: build the small parts first and assemble them later. Most non-trivial programs end up using a mix of both, but top-down is the discipline that protects the program's overall shape from being dictated by whichever low-level detail the designer happened to consider first.
Why it matters
How it works
Start with the problem statement and ask: if I had three or four named operations that solved subproblems, what would they be? Write them down as function calls in the order they would execute. Resist the urge to expand any single operation before all of them are listed — at this stage the goal is the overall shape, not the inner workings of any one piece. Each named operation becomes a contract: a description of inputs, outputs, and intent that the rest of the program will rely on.
Then pick one operation and decompose it the same way. Often this introduces new lower-level operations that did not appear at the top layer. Continue downward until each leaf is a single built-in operation or a handful of statements you can write without further design. Throughout the descent, the outline above remains stable: changes at lower levels do not ripple upward as long as the contracts at each layer are honoured. The result is a program whose top-level reads like a description of the problem and whose lower levels read like an implementation, with the abstraction levels cleanly separated.