Design Document
Ein Design Document ist ein schriftlicher Plan, in dem ein Entwicklerteam vor dem Programmieren festhält, was gebaut werden soll und warum genau so. Es beschreibt Ziel, Lösungsweg, verworfene Alternativen und offene Risiken und wird von Kolleginnen und Kollegen kommentiert, bevor die Arbeit beginnt.
Bevor ein Team ein größeres Stück Software baut, schreibt jemand auf, was genau entstehen soll. Dieses Schriftstück heißt Design Document, auf Deutsch etwa Entwurfsdokument. Darin steht das Problem, der geplante Lösungsweg und die Begründung dafür. Ebenso wichtig ist, was man bewusst nicht tut und welche anderen Wege man geprüft und verworfen hat. Das Dokument ist meist fünf bis zwanzig Seiten lang und kein Vertrag, sondern eine Diskussionsgrundlage. Andere im Team lesen es, schreiben Kommentare hinein und stellen unbequeme Fragen, solange noch nichts programmiert ist.
Warum Teams erst schreiben und dann bauen
Ein Fehler im Plan kostet fast nichts. Derselbe Fehler in fertigem Code kostet Wochen. Wer erst nach drei Monaten Arbeit merkt, dass die gewählte Datenbank die erwartete Last nicht trägt, muss große Teile neu bauen. Ein Design Document zieht solche Fragen nach vorne, in eine Phase, in der Umplanen nur bedeutet, einen Absatz umzuschreiben.
Der zweite Nutzen ist das Schreiben selbst. Eine Idee kann im Kopf schlüssig wirken und beim Aufschreiben auseinanderfallen. Sobald man einen Ablauf Schritt für Schritt formulieren muss, fallen Lücken auf. Erfahrene Entwicklerinnen sagen deshalb, das Dokument sei vor allem ein Werkzeug zum Nachdenken und erst danach ein Werkzeug zum Kommunizieren.
Dazu kommt das Gedächtnis des Teams. In zwei Jahren wird jemand fragen, warum eine Komponente so seltsam gebaut ist. Ohne Dokument bleibt nur Raten oder eine teure Umbauaktion. Mit Dokument findet man die damaligen Gründe, samt der Bedingungen, die inzwischen vielleicht nicht mehr gelten. Genau dieser Punkt macht den Unterschied zwischen einem gut begründeten Umbau und blindem Herumprobieren.
Was in so einem Dokument steht
Fast alle Design Documents folgen einem ähnlichen Aufbau. Am Anfang steht der Kontext: Welches Problem gibt es, wer hat es, warum jetzt? Danach folgen die Ziele und ausdrücklich auch die Nicht-Ziele. Ein Nicht-Ziel ist etwas, das man absichtlich weglässt, damit später niemand es stillschweigend erwartet.
Der Hauptteil beschreibt den Entwurf. Welche Bausteine gibt es, wie reden sie miteinander, wie fließen die Daten? Hier stehen oft grobe Zahlen: erwartete Anfragen pro Sekunde, Speicherbedarf, Kosten pro Monat. Solche Schätzungen müssen nicht exakt sein. Sie sollen zeigen, ob eine Idee um den Faktor zehn danebenliegt, und das merkt man nur, wenn man rechnet.
Ein eigener Abschnitt gehört den Alternativen. Dort steht, welche anderen Lösungen geprüft wurden und woran sie scheiterten. Am Ende folgen Risiken, offene Fragen und ein grober Zeitplan. Wichtig ist der Unterschied zur technischen Dokumentation: Ein Design Document blickt nach vorne und beschreibt eine Absicht. Eine Dokumentation blickt zurück und beschreibt, wie das fertige System tatsächlich funktioniert.
Vom Google-Alltag bis zu den KI-Laboren
Große Softwarefirmen wie Google, Amazon oder Microsoft arbeiten seit Jahrzehnten so. Bei Amazon gilt eine strenge Variante: statt Folien schreibt man einen Fließtext, der zu Beginn eines Meetings still gelesen wird. Erst danach wird diskutiert. In der Open-Source-Welt heißen ähnliche Papiere oft RFC, kurz für Request for Comments, also Bitte um Kommentare. Auch neue Funktionen in Programmiersprachen wie Python oder Rust durchlaufen solche öffentlich lesbaren Entwürfe.
In KI-Firmen sind Design Documents inzwischen genauso üblich wie im klassischen Softwarebau. Ein Trainingslauf für ein großes Sprachmodell kann Millionen kosten und Wochen dauern. Ein schlecht durchdachter Aufbau lässt sich nicht mal eben korrigieren. Deshalb wird vorher festgehalten, welche Daten verwendet werden, wie groß das Modell wird und woran man Erfolg misst.
Ein verbreiteter Irrtum ist, Design Documents seien Bürokratie, die das Arbeiten bremst. In der Praxis gilt eher eine Faustregel nach Aufwand: Für eine Änderung von zwei Tagen lohnt sich kein Dokument. Für ein Projekt über mehrere Monate mit vielen Beteiligten sind ein paar Tage Schreibarbeit fast immer billiger als der erste größere Irrweg. Wer in Stellenanzeigen liest, gute schriftliche Kommunikation sei gefragt, findet hier einen der Hauptgründe.
