Es gibt eine Form der Softwareentwicklung, die wie Fortschritt aussieht und keiner ist. Alle paar Tage wird eine Funktion ausgeliefert, die Demo wird jede Woche besser, und eine Zeit lang zeigt die Kurve nur nach oben. Dann kommt die dritte Integration, oder der erste echte Kunde mit echten Daten, und das Team stellt fest, dass die Form des Systems damit nicht zurechtkommt. Die Arbeit der nächsten sechs Monate besteht darin, die Arbeit der letzten drei rückgängig zu machen.
Wir haben uns für den umgekehrten Tausch entschieden. Unsere Projekte beginnen absichtlich langsam.
Tempo ist ein Kredit auf eine Entscheidung, die noch nicht gefallen ist
Das meiste frühe Tempo entsteht dadurch, dass Entscheidungen aufgeschoben statt getroffen werden. Man wählt kein Datenmodell, man übernimmt dasjenige, das der erste Bildschirm nahelegt. Man zieht keine Grenze zwischen zwei Anliegen, man lässt sie sich eine Datei teilen und verspricht, sie später zu trennen. Jeder Aufschub ist ein kleiner Kredit, und die Zinsen werden bei jeder weiteren Änderung fällig.
Die Kredite, die schmerzen, sind nicht die, vor denen üblicherweise gewarnt wird. Doppeltes Markup ist günstig zu beheben. Ein verwirrender Variablenname ist günstig zu beheben. Was nicht günstig ist:
- Das Datenmodell. Jeder Bildschirm, jeder Export, jede Berechtigungsprüfung und jede Integration hängt irgendwann von der Form Ihrer zentralen Entitäten ab. Ein Fehler hier erzeugt nicht einen Bug, sondern eine ganze Kategorie von Bugs, die über Jahre wiederkehrt.
- Grenzen zwischen Systemen. Sobald zwei Anliegen die Interna des jeweils anderen kennen, erfordert ihre Trennung Eingriffe in beide. Die Kosten dieser Trennung wachsen mit jeder Funktion, die über die Nahtstelle hinweg gebaut wird.
- Die Bedeutung eines Wortes. Wenn «Konto» in der Abrechnung etwas anderes bedeutet als im Reporting, wird die Mehrdeutigkeit in hundert Funktionen festgeschrieben, bevor jemand das Problem benennt.
Nichts davon lässt sich mit einem Refactoring-Sprint beheben. Behoben werden kann es nur mit einem Neubau, der teuersten Art, etwas zu lernen, das man durch eine Woche Nachdenken hätte lernen können.
Woraus der langsame Start tatsächlich besteht
Langsam zu bauen ist nicht dasselbe, wie in einem allgemeinen Sinn sorgfältig zu bauen. Es ist eine bestimmte Abfolge von Tätigkeiten, und sie finden statt, bevor es viel zu sehen gibt.
In der ersten Phase versuchen wir, das Problem in einem Satz zu formulieren. Nicht die Lösung, das Problem. Das ist schwieriger, als es klingt, und hier scheitern die meisten Produkte, ohne dass es jemand bemerkt. Ein Problem, das man nicht präzise formulieren kann, löst man nur ungefähr, und eine ungefähre Lösung für ein unklares Problem ist nicht zu unterscheiden von einem Produkt, das niemand braucht.
Dann das Modell. Wir beschreiben die Entitäten, ihre Beziehungen und ihre Invarianten, bevor wir einen Bildschirm entwerfen, denn die Bildschirme folgen aus dem Modell und nicht umgekehrt. Ist das Modell richtig, lassen sich Oberflächen mit wenig Aufwand ändern und über Jahre weiter verbessern. Ist das Modell falsch, kann keine noch so grosse Arbeit an der Oberfläche es verbergen.
Dann die Grenzen. Wir legen fest, was jeder Teil des Systems wissen darf, und wir halten das schriftlich fest. Grenzen sind der einzige Schutz vor dem Fehlermuster, bei dem eine Codebasis technisch funktioniert und praktisch nicht mehr veränderbar ist.
Erst dann beginnt die Umsetzung, und sie geht vergleichsweise schnell, weil die teuren Fragen bereits beantwortet sind.
Das Messproblem
Die ehrliche Schwierigkeit dieses Ansatzes ist, dass er sich kaum vorzeigen lässt, während er stattfindet. Ein Team, das drei Wochen an einem Datenmodell arbeitet, hat am Ende nichts vorzuweisen ausser einem Dokument und einigen Typdefinitionen. Ein Team, das drei Wochen lang Bildschirme baut, hat Bildschirme.
Der Unterschied zeigt sich später, und er zeigt sich als Abwesenheit. Es gibt keinen Neubau. Es gibt keinen Monat, in dem Daten migriert werden müssen, weil eine Spalte zwei Dinge bedeutete. Es gibt keine Funktion, die sich als unmöglich herausstellt. Abwesenheiten lassen sich schwer in einen Fortschrittsbericht schreiben, und genau deshalb weisen die Anreize in den meisten Unternehmen in die andere Richtung.
Wir nehmen diese Kosten in Kauf, weil wir besitzen, was wir bauen. Niemand verlangt von uns, in diesem Quartal eine Kurve zu zeigen, also können wir auf den Zustand des Systems im fünften Jahr optimieren statt auf den Zustand der Demo in der dritten Woche.
Wohin Tempo gehört
Das ist kein Plädoyer für Langsamkeit als Tugend. Langsamkeit am falschen Ort ist schlicht Verschwendung.
Sobald Modell und Grenzen feststehen, wollen wir sehr schnell vorankommen, und genau darin liegt der Sinn des langsamen Starts: dass wir es können. Klar definierte Systeme lassen sich angenehm erweitern. Eine neue Funktion ist eine lokale Änderung und keine Verhandlung mit der gesamten Codebasis. Das Tempo kommt später, aber es kommt und bleibt dann, statt nachzulassen, während das System Entscheidungen ansammelt, die niemand bewusst getroffen hat.
Software, die ein Jahrzehnt überdauert, ist nicht Software, die in einem allgemeinen Sinn mit mehr Sorgfalt gebaut wurde. Es ist Software, bei der die wenigen wirklich unumkehrbaren Entscheidungen langsam getroffen wurden und alles andere schnell.