Fred Brooks: Das Schwierige war nie das Tippen

8 Min. Lesezeit

Die Oberfläche funktionierte. Die Einigung fehlte.

Er hatte das Chaos selbst geleitet

Fred Brooks prägte IBMs System/360 mit und leitete die Arbeit am Betriebssystem OS/360. Aus dieser Erfahrung entstand seine Darstellung der Softwareentwicklung. In seinem Zeitzeugeninterview mit Grady Booch von 2007 erinnert er sich, wie Thomas Watson Jr. ihn fragte, worin sich die Leitung von Hardware- und Softwareprojekten unterscheide. Das Nachdenken über diese Frage wurde zum Ausgangspunkt für The Mythical Man-Month.

Das Interview enthält außerdem etwas Nützlicheres als einen heldenhaften Lebenslauf. Nach seiner schlechtesten Entscheidung gefragt, beschreibt Brooks, wie er die Architekturverantwortung von der Architekturgruppe auf den Betriebssystemmanager übertrug. Er benennt seinen eigenen Fehler. Der Mann, der erklärte, warum Softwareprojekte scheitern, hatte selbst zu einem solchen Scheitern beigetragen.

Das macht ihn zu einem nützlichen Begleiter, wenn das nächste beeindruckende Werkzeug mit der Andeutung auftaucht, der schwierige Teil sei nun endlich verschwunden. Er hilft uns, die Arbeit hinter dem Versprechen zu untersuchen.

Zwei Arten von Schwierigkeit, eine bequeme Verwechslung

In No Silver Bullet, seinem Aufsatz von 1986, unterschied Brooks essenzielle Schwierigkeiten – die konzeptionelle Arbeit des Spezifizierens, Entwerfens und Prüfens eines Systems – von akzidentellen: dem Aufwand, diese Konzepte in Code darzustellen und zu prüfen, ob der Code sie getreu ausdrückt. Als dauerhafte Probleme benannte er Komplexität, die notwendige Anpassung an andere Systeme und Institutionen, Veränderlichkeit und Unsichtbarkeit. Seine Prognose lautete, dass kein einzelner technischer oder organisatorischer Fortschritt innerhalb eines Jahrzehnts eine Verzehnfachung bei Produktivität, Zuverlässigkeit oder Einfachheit bringen würde. Eine Messung der Leistungsfähigkeit heutiger KI ist das nicht.

Zu dieser konzeptionellen Arbeit gehören Datenbeziehungen, Algorithmen und das Zusammenspiel der Systemteile. Mit der Einigung auf eine Geschäftsregel beginnt die Designarbeit. Abgeschlossen ist sie damit nicht.

Nehmen wir einen erfundenen Großhändler, der telefonische Bestellungen durch einen Onlinedienst ersetzt. Das Formular zu bauen, mag einfach sein. Zu entscheiden, wann aus einer Bestellung eine Zusage wird, ist eine andere Sache.

Der Vertrieb versteht die Bestätigung als Verpflichtung. Das Lager betrachtet sie als Anfrage, bis der Bestand zugeteilt ist. Die Buchhaltung hält sie für vorläufig, bis die Bonität des Kunden geprüft wurde. Alle drei Abteilungen können belegen, dass ihre Auslegung seit Jahren funktioniert. Alle drei können auch auf einen Kollegen zeigen, der die heiklen Fälle stillschweigend klärt.

Jetzt braucht die Software eine Regel. Aus dem Ermessensspielraum des Kollegen muss eine ausdrückliche Entscheidung werden, eine Ausnahme mit einem Verantwortlichen oder ein Grund, einen Teil der Arbeit manuell zu lassen. Ein Entwickler, der danach fragt, hat seine Aufgabe erkannt. Ihm zu sagen, er solle nicht alles zerdenken und endlich das Formular fertig machen, sorgt lediglich dafür, dass sich die Annahme eines anderen ungeprüft durchsetzt.

Der Code kann völlig ordentlich sein. Die Zusage trotzdem falsch.

Die Ausnahme gehört zum Produkt

Nun storniert der Kunde, nachdem die Kommissionierung begonnen hat. Er drückt den Knopf, während ein Lagermitarbeiter zum Regal geht. Soll der Auftrag vom Gerät des Mitarbeiters verschwinden? Soll der Mitarbeiter die Stornierung zuerst bestätigen? Was soll der Kunde sehen, solange diese Bestätigung fehlt?

Angenommen, die Verbindung im Lager bricht ab. Der Kunde hat eine Stornierungsbestätigung erhalten, aber der Mitarbeiter arbeitet seine heruntergeladene Liste weiter ab. Ein Paketdienst holt das Paket ab. Nun hat das Unternehmen Ware zu einem Auftrag versandt, dessen Stornierung es dem Kunden bereits bestätigt hat.

Diese Fragen betreffen die Implementierung ebenso wie den Geschäftsablauf. Sie beeinflussen Zustandswechsel, gespeicherte Datensätze, Nachrichten, Wiederholungsversuche und die Oberfläche, mit der jemand den Fehler beheben muss. Der Entwickler braucht genug technisches Verständnis, um den Fehler sichtbar zu machen, und genug Zugang zu den Beteiligten, um eine akzeptable Reaktion festzulegen.

Jemand könnte eine einfachere Geschäftsregel vorschlagen: Sobald die Kommissionierung beginnt, wird aus der Stornierung eine Anfrage. Der Kunde sieht diesen Unterschied sofort. Diese Entscheidung könnte mehrere technische Probleme beseitigen. Sie verändert allerdings auch die angebotene Leistung. Die dafür Verantwortlichen müssen ihr zustimmen.

Selbst nach dieser Einigung bleibt Designarbeit übrig. Was gilt als Beginn der Kommissionierung: wenn der Mitarbeiter ins Regal greift, das Gerät den Vorgang erfasst oder der Server ihn annimmt? Was geschieht, wenn Kommissionierung und Stornierung gleichzeitig beim Server eintreffen? Erst zu prüfen, ob ein Auftrag noch wartet, und ihn dann zu stornieren, lässt dazwischen Raum für den Beginn der Kommissionierung. Das System muss diesen Wettlauf widerspruchsfrei auflösen. Dazu gehört auch, was ein Mitarbeiter ohne Verbindung tun darf, bevor sein Gerät wieder online ist.

Deshalb verdient eine Ausnahme mehr Aufmerksamkeit, als der Ausdruck „Sonderfall“ manchmal vermuten lässt. Im Normalfall können mehrere unvereinbare Vorstellungen friedlich nebeneinander bestehen. Die Ausnahme lässt sie aufeinandertreffen.

Ein Prototyp kann das Denken verbessern

Brooks empfahl, Anforderungen mithilfe von Prototypen zu verfeinern und lauffähige Software schrittweise wachsen zu lassen. Er zeigte einen praktischen Weg zum Lernen, statt zu verlangen, vor dem ersten Code alles zu Ende zu denken. Diese Empfehlung ist ebenso wichtig wie die berühmte Warnung vor Wunderwerkzeugen. Der Originalaufsatz enthält beides.

Für den Großhändler reicht zunächst die kleinste Version, die das Stornierungsproblem sichtbar macht. Eine Person gibt eine Musterbestellung auf, eine andere beginnt, sie zusammenzustellen. Mittendrin stornieren. Die Lagerverbindung unterbrechen. Beide fragen, was ihrer Meinung nach passiert ist. Dann ihre Antworten mit den Aufzeichnungen des Systems vergleichen.

Das erste nützliche Ergebnis kann ein unangenehmes Gespräch sein. Gut. Es fand statt, bevor das Unternehmen zehntausend Kunden importierte und verkündete, das Bestellen sei revolutioniert worden.

Sobald die Beteiligten sich auf das Verhalten geeinigt haben, konkrete Beispiele in automatisierten Prüfungen festhalten. Dazu gehören die späte Stornierung, das gleichzeitige Eintreffen von Kommissionierung und Stornierung, die unterbrochene Verbindung und eine wiederholte Nachricht. Eine kleine Änderung durch Integration und Release führen, damit das Team Probleme in der tatsächlichen Umgebung entdecken kann. Kent Becks Feedbackdisziplin ergänzt diesen Ansatz sinnvoll: lernen, solange die Änderung noch klein genug ist, um sie zu verstehen.

Die Arbeit ist vorangekommen, wenn Menschen erklären und vorführen können, was geschieht. Die Zahl der Oberflächen ist dafür ein ziemlich schlechter Ersatz.

KI kann bei mehr helfen als beim Tippen

Brooks’ Unterscheidung auf KI anzuwenden, verlangt etwas Sorgfalt. Ein Assistent kann helfen, Alternativen zu formulieren, eine bestehende Implementierung nachzuvollziehen, widersprüchliche Regeln aufzuspüren und Experimente vorzuschlagen. Das kann zur konzeptionellen Arbeit beitragen. Wer jeden KI-Beitrag als bloßes Tippen behandelt, übersieht einen großen Teil des möglichen Nutzens.

Gib dem Assistenten im Stornierungsbeispiel die vereinbarten Randbedingungen. Lass ihn nachvollziehen, wo die Stornierung derzeit Bestand, Zahlung und Versand beeinflusst. Frage, was geschieht, wenn jede Nachricht doppelt oder in falscher Reihenfolge eintrifft. Lass ihn sofortige Stornierung und Stornierungsanfrage vergleichen und beschreiben, wer bei welchem Entwurf die Unannehmlichkeiten trägt. Prüfe seine Antworten am Quellcode, an den tatsächlichen Schnittstellen und mit den Menschen, die die Aufträge bearbeiten.

Ein Assistent kann auch einen Prototyp entwerfen, der diese Alternativen leichter besprechbar macht. Eine günstige Implementierung wird wertvoll, weil das Team eine Idee prüfen kann, über die es vorher nur streiten konnte.

Eine plausible Antwort hat aber keine Befugnis, den Anspruch eines Kunden oder die Verantwortung eines Lagermitarbeiters zu ändern. Füllt der Assistent eine Lücke mit einer vertrauten Konvention, bleibt diese Konvention ein Vorschlag. Laufender Code kann die Annahme ebenso gut verbergen wie ein selbstsicherer Absatz.

Die nützliche Grenze verläuft zwischen einem Vorschlag und dem Nachweis, dass er passt. Um sie zu überschreiten, braucht es weiterhin Kontakt mit dem System und den Menschen, deren Arbeit sich dadurch verändert.

Auch Komplexität muss sich rechtfertigen

Ein Problem als wesentlich zu bezeichnen, kann selbst zur Ausrede werden. Vielleicht hat der Großhändler sechs Stornierungsregeln, weil sechs frühere Manager jeweils eine Sondervereinbarung ausgehandelt haben. Vielleicht existieren zwei Schnittstellen nur, weil niemand einen alten Import abgeschaltet hat. Jede geerbte Komplikation zu bewahren, würde aus der neuen Software ein ungewöhnlich teures Museum machen.

Frage, welche Zusagen tatsächlich gelten, welche Randbedingungen noch bestehen und welche Abläufe das Unternehmen ändern will. Manchmal beginnt die beste technische Vereinfachung damit, eine geschäftliche Ausnahme abzuschaffen. Manchmal schützt die unbequeme Regel eine wertvolle Kundenbeziehung und muss bleiben. Das muss untersucht werden. Eleganter Code allein liefert die Antwort nicht.

Das lässt auch Raum für gewöhnliche, erhebliche Verbesserungen. Eine bessere Bibliothek, eine reparierte Entwicklungsumgebung oder ein Assistent für wiederkehrende Änderungen können viel zermürbende Arbeit abnehmen. Die Provokation im Titel hat eine Grenze: Implementierung verursacht reale Kosten, und sie zu senken, zählt. Der Fehler liegt in der Annahme, diese Einsparungen erledigten jede andere Art von Arbeit gleich mit.

Mary Poppendieck machte ein verwandtes Problem sichtbar: Wer einen einzelnen Arbeitsschritt beschleunigt, macht damit noch nicht den gesamten Ablauf schneller. Hier kann es an der Einigung darüber fehlen, was die Software eigentlich zusagen soll.

Welche Ungewissheit hast du beseitigt?

Zurück beim Großhändler unterscheidet der Stornierungsknopf nun zwischen einem stornierten Auftrag und einer Anfrage, die auf die Bestätigung des Lagers wartet. Ein Mitarbeiter ohne Verbindung erhält die Anfrage, sobald sein Gerät wieder online ist. Bis das Lager den Stopp bestätigt, sieht der Kunde die Stornierung als ausstehend. Jemand kümmert sich um Anfragen, die unbeantwortet bleiben. Die Buchhaltung kann jede daraus entstehende Zahlungskorrektur nachvollziehen. Das Team hat diese Übergänge gemeinsam geprüft, auch den Wettlauf zwischen Kommissionierung und Stornierung.

Diese Version enthält vielleicht weniger Funktionen als die erste Vorführung. Sie enthält eine deutlich bessere Antwort.

Brooks verdient eine erneute Lektüre, sobald die Branche eine leichtere Implementierung mit abgeschlossenem Verständnis verwechselt. Sein Argument führt zu einer Frage, die sich auf jedes neue Werkzeug und jede neue Änderung anwenden lässt: Welchen Teil der Schwierigkeit hat das tatsächlich beseitigt?

Wenn es wiederkehrende Implementierungsarbeit ist, freue dich über die Ersparnis. Wenn eine Annahme aufgedeckt und korrigiert wurde, umso besser. Wenn es niemand sagen kann, ist womöglich nur die Vorführung überzeugender geworden.

Das Lager wird ohnehin irgendwann fragen.