Top-down design is een manier van software bouwen die begint bij het hele systeem en dat opdeelt in steeds kleinere onderdelen, tot elk stukje simpel genoeg is om te schrijven. Je start met één grote vraag, “wat moet dit systeem doen?”, en splitst dat antwoord telkens verder op in duidelijke deeltaken. Elke laag dieper wordt concreter.
Denk aan het plannen van een bruiloft. Je begint niet met de kleur van de servetten. Je begint met de grote blokken: locatie, eten, gasten, muziek. Daarna deel je “eten” op in voorgerecht, hoofdgerecht en dessert, en pas dan in losse recepten. Software werkt net zo: je tekent eerst de structuur op hoofdlijnen, en daalt dan af naar de details. Dit past goed bij abstractie, waarbij elke laag de rommelige details van de laag eronder verbergt.
De tegenovergestelde aanpak is bottom-up design, waarbij je eerst kleine, herbruikbare stukjes bouwt en die later samenvoegt. Geen van beide is automatisch beter. Top-down geeft je vroeg een helder plan en gedeelde taal, handig als veel mensen aan hetzelfde project werken. Het maakt ook een geschreven ontwerpdocument een stuk makkelijker te maken, want de vorm van het systeem staat al op papier voordat iemand een editor opent. Het risico is de keerzijde van die kracht: diep in de details kun je ontdekken dat een vroege aanname niet klopte, en hoe later je dat merkt, hoe duurder het terugdraaien wordt. Daarom schetsen de meeste teams de bovenste lagen en bouwen ze daarna één dunne plak helemaal naar beneden, om de riskantste gok meteen te toetsen.
Bij TopDevs starten we meestal top-down om met de klant de vorm van een systeem af te spreken, en schakelen we daarna snel naar echte stukjes bouwen, zodat we aannames toetsen voordat ze duur worden.
