Manche Probleme der Softwareentwicklung sind keine Fehler, die sich beheben ließen, sondern strukturelle Eigenschaften der Disziplin. Es sind Dauerthemen, die Entwicklerinnen und Entwickler seit Jahrzehnten begleiten und auch in den nächsten Jahrzehnten begleiten werden.
Dieser Artikel ist der erste Teil einer Serie, die Probleme beleuchtet, die sich nicht wegoptimieren lassen: Won’t fix – wie irreparable Issues in GitHub-Repositories heißen.
Wie lange braucht man, um ein Osterei zu bemalen? Ein bisschen Wiese, einen Osterhasen, eine Sonne und einige Wolken am Himmel, einschließlich Ausblasen und das Einfädeln des an ein Streichholz geknoteten Fadens. 10 Minuten? 15 Minuten? Eine halbe Stunde? Oder gar eine ganze Stunde? Selbst bei einer Aufgabe, deren Anforderungen klar und deren Prozess seit der Kindheit bestens bekannt sind, bewegen sich die Antworten zwischen 10 Minuten und einer Stunde, was einer Spanne von 500 Prozent entspricht.
Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss. Die Serie "Wont' fix" behandelt Probleme in der Softwareentwicklung, die sich nicht wegoptimieren lassen, mit denen man aber lernen kann umzugehen:
In der Softwarebranche gelten solche Schwankungen als inakzeptabel. Dort sollen Entwicklerinnen und Entwickler bei unvergleichlich komplexeren Aufgaben, deren Anforderungen häufig noch nicht einmal vollständig bekannt sind, verlässliche Vorhersagen über Kosten und Zeitrahmen treffen. „Wie teuer wird es, und wie lange wird es dauern?“ sind die gängigen Fragen, auf die Kundinnen und Kunden eine belastbare Antwort erwarten.
Doch Studien in der Softwarebranche zeigen seit Jahrzehnten ein konsistentes Bild: Projekte dauern länger als geplant, kosten mehr als veranschlagt und liefern weniger als versprochen. Dieses Muster zieht sich durch alle Themen, alle Unternehmensgrößen und alle Methoden. Weder Wasserfall noch Agile noch irgendetwas dazwischen haben daran grundlegend etwas geändert. Dass verlässliche Vorhersagen regelmäßig scheitern, überrascht bei näherer Betrachtung weniger als die Erwartung, dass es passen sollte.
Bevor sich die Frage beantworten lässt, warum Softwareschätzungen so häufig danebenliegen, lohnt es sich, einen Schritt zurückzutreten: Warum wird überhaupt geschätzt? Die Antwort ist weniger offensichtlich, als sie scheint, denn hinter der Frage „Wie lange dauert das?“ verbergen sich ganz unterschiedliche Anliegen.
Manchmal geht es um eine Kostenvorhersage. Ein Unternehmen möchte wissen, ob sich eine Investition lohnt, und benötigt eine Zahl für die Budgetplanung. Manchmal geht es um eine Zeitvorhersage, etwa weil ein Marktereignis einen Termin diktiert. Und manchmal geht es schlicht um die Machbarkeit: Ist das überhaupt realisierbar und wenn ja, in welcher Größenordnung bewegt sich der Aufwand?
Diese Unterscheidung wird in der Praxis selten getroffen, obwohl sie entscheidend ist. Wer die Machbarkeit prüfen will, benötigt keine Stundenzahl. Wer ein Jahresbudget plant, benötigt keine Präzision auf Tagesebene. Und wer einen festen Liefertermin benötigt, dem hilft eine Aufwandsschätzung in Story-Points wenig. Hinzu kommt ein weiteres Missverständnis: Eine Schätzung wird oft als Zusage behandelt, obwohl sie ihrem Wesen nach eine Annäherung unter Unsicherheit ist. Wer eine Schätzung abgibt, kommuniziert eine Erwartung. Wer eine Schätzung entgegennimmt, versteht häufig ein Versprechen. Dieser Unterschied mag subtil klingen, ist aber in der Praxis die Quelle zahlloser Konflikte zwischen Entwicklungsteams und ihren Auftraggebern.
Die Softwarebranche leistet einer fundamentalen Fehleinschätzung Vorschub, indem sie über Produktionseffizienz, Softwarefabriken und Durchsatz spricht, als ginge es um die Fertigung von Bauteilen am Fließband. Diese Formulierungen suggerieren einen industriellen, reproduzierbaren Prozess, bei dem Schätzungen möglich und sinnvoll sind, weil das Fließband den Takt bestimmt.
Softwareentwicklung aber ist keine Produktion. Der Name sagt es bereits: Es ist Entwicklung. Ein kreativer, in gewissem Sinne sogar künstlerischer Prozess. Der herausragende US-amerikanische Informatiker Donald E. Knuth nannte sein Lebenswerk „The Art of Computer Programming“ und prägte mit dem Konzept des Literate Programming die Idee, dass Programme nicht nur funktionieren, sondern auch lesbar und ästhetisch sein sollten. Seine damit verbundene Frage hat nichts von ihrer Aktualität verloren: „Wann haben Sie das letzte Mal einen angenehmen Abend in einem bequemen Sessel verbracht und dabei ein gutes Programm gelesen?“ Dass diese Frage für die meisten Menschen absurd klingt, sagt viel über das Missverständnis der Branche gegenüber ihrem eigenen Tun.
Software ist ausführbares Wissen. Und Wissen lässt sich nicht auf Verlangen in einem vorgegebenen zeitlichen oder finanziellen Rahmen erzeugen. Es entsteht durch Entdecken, Erfinden und Verstehen. Und dieser Prozess lässt sich nicht takten. Ideen kommen, wenn der kreative Freiraum dafür besteht, nicht wenn der Projektplan sie vorsieht. Fred Brooks unterschied bereits 1986 in seinem Essay „No Silver Bullet“ zwischen wesentlicher und akzidentieller Komplexität. Die akzidentielle Komplexität lässt sich durch bessere Werkzeuge und Methoden reduzieren: bessere Editoren, leistungsfähigere Frameworks, effizientere Build-Systeme. Die wesentliche Komplexität aber steckt im Problem selbst und kein Tool der Welt kann sie beseitigen. Sie ist der Teil der Aufgabe, der übrig bleibt, wenn alle technischen Hürden beseitigt sind.
Wer Software schätzt, versucht im Grunde vorherzusagen, wie lange es dauert, ein Problem zu verstehen, das noch niemand vollständig verstanden hat. Dass diese Vorhersage selten stimmt, ist weniger erstaunlich als die Tatsache, dass sie trotzdem ständig verlangt wird.
Eine Metapher macht das greifbar. Angenommen, jemand soll vorhersagen, wie lange eine Wanderung von Berlin nach München dauert. Die Rechnung scheint einfach: Entfernung auf der Karte abmessen, eine durchschnittliche Gehgeschwindigkeit ansetzen, fertig. Auf dem Papier sieht das überzeugend aus.
In der Realität nicht. Die Karte zeigt keine Höhenunterschiede, zumindest nicht im erforderlichen Detail. Sie zeigt nicht, dass Wege gesperrt sein können, dass Flüsse überquert werden müssen und erst eine Brücke gefunden werden will, dass das Wetter umschlagen kann und dass Umwege unvermeidlich sind. Wer schon einmal gewandert ist, weiß, dass selbst auf einer vermeintlich bekannten Route Überraschungen lauern: ein umgestürzter Baum, eine Baustelle, ein falsch abgebogener Pfad, der einen Kilometer extra kostet. Der Plan und der tatsächliche Weg haben wenig miteinander zu tun.
Softwareprojekte verhalten sich genauso. Die Spezifikation ist die Karte, der Code ist der Weg. Und zwischen beiden liegt das unbekannte Gelände: Bibliotheken, die sich anders verhalten als dokumentiert, Anforderungen, die sich erst während der Umsetzung als widersprüchlich herausstellen, technische Schulden in bestehenden Systemen, die niemand auf der Karte verzeichnet hat.
In der Softwareentwicklung beschreibt der Cone of Uncertainty genau dieses Phänomen. Er besagt, dass die Unschärfe einer Schätzung zu Projektbeginn am größten ist und erst im Verlauf des Projekts abnimmt, je mehr über das Problem und seine Lösung bekannt wird. Zu Beginn eines Projekts kann die tatsächliche Dauer um den Faktor vier nach oben oder unten vom Schätzwert abweichen. Erst wenn ein signifikanter Teil der Arbeit bereits geleistet ist, nähert sich die Schätzung der Realität an. Das Paradoxe daran: Genau zu Beginn, wenn die Unsicherheit am größten ist, werden Budgets festgelegt, Verträge geschlossen und Timelines kommuniziert. Es ist, als würde man die Wanderung planen, ohne je einen Blick auf das Gelände geworfen zu haben, und dann den errechneten Zeitplan als verbindlich betrachten.
Auch wenn die strukturellen Schwierigkeiten bekannt sind, bleibt ein zweites Problem: Der menschliche Verstand arbeitet systematisch gegen realistische Einschätzungen. Die Psychologen Daniel Kahneman und Amos Tversky beschrieben in den 1970er-Jahren die Planning Fallacy, die Beobachtung, dass Menschen Projekte systematisch zu optimistisch einschätzen, selbst wenn sie über Erfahrung mit ähnlichen Vorhaben verfügen. Das Bemerkenswerte an der Planning Fallacy ist, dass Wissen um ihre Existenz kaum hilft: Selbst wer weiß, dass die eigene letzte Schätzung um den Faktor drei daneben lag, wird die nächste Schätzung nicht entsprechend korrigieren. Der Optimism Bias sorgt dafür, dass man Risiken und Hindernisse unterschätzt. Der Ankereffekt bewirkt, dass die erste genannte Zahl alle weiteren Schätzungen in ihre Richtung zieht, unabhängig davon, wie gut diese erste Zahl begründet war.
In Teams kommen Gruppeneffekte hinzu. Beim Planning-Poker etwa, einer verbreiteten Schätzmethode in agilen Teams, schätzen alle Beteiligten gleichzeitig, um genau diese gegenseitige Beeinflussung zu reduzieren. Die Methode enthält noch ein weiteres stilles Eingeständnis: Die verwendeten Werte entsprechen einer angenäherten Fibonacci-Folge. Kleine Aufgaben lassen sich feingranular einordnen, deshalb gibt es die Werte 1, 2, 3 und 5. Große Aufgaben hingegen lassen sich nur noch grob schätzen. Dort genügt eine 13, eine 20 oder eine 40. Die Skala selbst bildet ab, was die Branche längst weiß: je größer die Aufgabe, desto unzuverlässiger die Schätzung.
Ein weiterer oft unterschätzter Faktor ist die Verwechslung von Code Complete mit Feature Complete. Viele Schätzungen enden gedanklich beim abschließenden Commit. Aber zum fertigen Feature gehören auch Debugging, Fehlersuche, Testen, Integration, Code Review, Dokumentation und Deployment. Diese Tätigkeiten machen häufig den größeren Teil des Gesamtaufwands aus, tauchen in der ursprünglichen Schätzung aber häufig nicht auf.
Dazu kommt ein Phänomen, das Fred Brooks bereits 1975 in „The Mythical Man-Month“ beschrieb und das als Brook's Law bekannt ist: Wenn ein Softwareprojekt in Verzug gerät und zusätzliche Mitarbeiterinnen und Mitarbeiter hinzugezogen werden, wird es noch später fertig. Der Kommunikationsaufwand in einem Team wächst quadratisch mit der Teamgröße und die Einarbeitung neuer Kolleginnen und Kollegen bindet Kapazitäten bei denen, die ohnehin schon unter Druck stehen. Zwischen je zwei Personen entsteht ein Kommunikationskanal. Ein Team von 5 Personen hat deshalb 10 solcher Kanäle, ein Team von 10 bereits 45. Jede zusätzliche Person bringt nicht nur einen neuen Kanal mit, sondern so viele, wie es bereits Teammitglieder gibt. Mit anderen Worten: Jede zusätzliche Person erhöht nicht nur die Kapazität, sondern auch den Koordinationsaufwand und ab einem bestimmten Punkt überwiegt der Aufwand den Nutzen. Diese Erkenntnis ist seit einem halben Jahrhundert bekannt und wird trotzdem regelmäßig ignoriert.
Wenn Schätzungen aus strukturellen und psychologischen Gründen unzuverlässig sind, stellt sich die Frage, ob es bessere Ansätze gibt. Die gibt es tatsächlich, auch wenn keiner das Grundproblem löst.
Die Bewegung unter dem Schlagwort No Estimates vertritt die radikalste Position: Statt besser zu schätzen, sollte man die Frage ändern. Wenn Arbeit in so kleine Einheiten zerlegt wird, dass jede davon in wenigen Tagen abgeschlossen werden kann, verliert die Frage nach der Gesamtschätzung an Bedeutung. Der Fortschritt wird nicht prognostiziert, sondern gemessen. Was gestern geliefert wurde, ist ein besserer Indikator für morgen als jede Schätzung von vor drei Monaten.
Wer dennoch eine Vorhersage benötigt, findet in probabilistischen Methoden einen Mittelweg. Monte-Carlo-Simulationen etwa nutzen historische Daten, um nicht einen einzelnen Schätzwert, sondern eine Wahrscheinlichkeitsverteilung zu erzeugen: „Mit 85 Prozent Wahrscheinlichkeit sind wir in acht bis zwölf Wochen fertig“ ist eine ehrlichere Aussage als „Das dauert zehn Wochen“. Sie macht die Unsicherheit sichtbar, statt sie hinter einer Pseudopräzision zu verstecken. Und sie zwingt alle Beteiligten, über Risikotoleranz zu sprechen, statt über vermeintlich feste Termine.
Der vielleicht wirksamste Ansatz ist jedoch ein grundsätzlich anderer Umgang mit der Frage. Statt ein Projekt als monolithischen Block zu denken, der vorab vollständig geschätzt und geplant werden muss, lässt sich in vielen Fällen iterativ vorgehen. Schritt für Schritt, solange, bis das Ergebnis gut genug ist oder bis das investierte Budget erschöpft ist. Wenn eine Software von Anfang an Wertschöpfung liefert, wenn jede Iteration ein nutzbares Ergebnis hervorbringt, dann verschiebt sich die Frage von „Wann ist alles fertig?“ zu „Lohnt sich der nächste Schritt noch?“. Die Entscheidung über Fortführung oder Abbruch wird dann nicht auf Basis einer Schätzung getroffen, die Monate zurückliegt, sondern auf Basis des tatsächlich erreichten Fortschritts und des investierten Aufwands.
Das funktioniert nicht in jedem Kontext, etwa wenn regulatorische Anforderungen ein vollständiges System voraussetzen oder wenn ein physisches Produkt zu einem festen Termin ausgeliefert werden muss. Aber in überraschend vielen Fällen ist es ein tragfähiger Ansatz, der zumindest eine ehrliche Diskussion wert ist. Er verlagert das Risiko von einer großen Vorabentscheidung auf viele kleine Entscheidungen im Verlauf, bei denen jeweils mehr Wissen zur Verfügung steht als zu Beginn.
Der deutsche Typograph Paul Renner schrieb einst: „Der Glaube an das Zählen und Messen verführt in allen Künsten zu den gröbsten Fehlern.“ Die Softwarebranche ist diesem Trugschluss erlegen, dass sich ein kreativer Prozess mit denselben Methoden planen ließe wie ein industrieller. Softwareschätzungen scheitern nicht an mangelnder Disziplin, nicht an fehlender Erfahrung und nicht an schlechten Werkzeugen. Sie scheitern an der Natur von Software als ausführbares Wissen und an der Natur menschlichen Denkens, gleichzeitig und auf eine Weise, die sich nicht einfach wegoptimieren lässt.
Wer das akzeptiert, kann anders mit Schätzungen umgehen. Andere Fragen stellen, andere Formate wählen, andere Erwartungen setzen. Schätzungen als das behandeln, was sie sind: Annäherungen unter Unsicherheit, die regelmäßig überprüft und angepasst werden müssen. Und vor allem aufhören, Schätzungen als Versprechen zu behandeln, denn genau das sind sie nicht, und genau das können sie nicht sein.
Die Illusion, ein kreativer Prozess ließe sich wie eine Fertigungsstraße planen, ist dabei nur eine von mehreren, denen die Softwarebranche erlegen ist. Eine andere, mindestens ebenso hartnäckige, betrifft die Frage nach der Fehlerfreiheit: die Vorstellung, dass sich Bugs mit genügend Sorgfalt und den richtigen Werkzeugen vollständig vermeiden ließen.
Warum auch das eine Illusion ist, und warum selbst „Hello World“ einen Bug enthält, ist Thema des zweiten Teils.
(who)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。