Lehmans Gesetze der Softwareevolution: Warum Code still verrottet (und wie man gegensteuert)

Software bricht nicht so, wie Brücken brechen. Eine Brücke, die nie angefasst wird, kann fünfzig Jahre oder länger stehen, manche sogar deutlich länger. Eine Codebasis, die nie angefasst wird, tut das Gegenteil: Sie verrottet still. Die Welt um sie herum verändert sich (Betriebssysteme aktualisieren sich, APIs werden abgekündigt, Vorschriften ändern sich, Nutzer erwarten mehr) und das unangetastete Programm, eingefroren an Ort und Stelle, wird mit jedem einzelnen Tag ein bisschen weniger nützlich, bis es eines Morgens schlicht aufhört zu funktionieren.

Das ist keine Meinung. Es kommt eher der Physik nahe. Vor mehr als fünfzig Jahren bemerkte ein Forscher bei IBM, dass sich große Softwaresysteme im Laufe ihres Alterns nach überraschend konsistenten Mustern verhalten, und er verbrachte zwei Jahrzehnte damit, diese Beobachtungen in eine Reihe empirischer Gesetze zu fassen, die heute als Lehmans Gesetze der Softwareevolution bekannt sind. Sie beschreiben dein Sprint-Board auch heute noch, ob du je von ihnen gehört hast oder nicht.

Lernen wir die Gesetze kennen: woher sie stammen, wo sie standhalten, wo sie brechen und, am wichtigsten, wie du sie in diesem Quartal auf reale Projekte anwendest.

Eine Studie, die ganz nebenbei ein Forschungsfeld begründete

Meir "Manny" Lehman. Foto: Hilehman, CC BY-SA 4.0, via Wikimedia Commons.

In den späten 1960er-Jahren baute IBM OS/360, eines der ambitioniertesten Softwareprojekte seiner Zeit. Meir “Manny” Lehman begann zusammen mit seinem Kollegen László Bélády, die Release-Historie dieses Systems zu untersuchen, und maß, wie sich seine Größe, seine Fehlerzahlen und der Aufwand für Änderungen von Release zu Release entwickelten. (Bélády und Lehman veröffentlichten 1976 ein frühes Modell davon im IBM Systems Journal.)

Was 1974 als drei Beobachtungen begann, wuchs bis 1978 auf fünf und bis 1996 auf eine Sammlung von acht Gesetzen der Softwareevolution. Lehman gilt heute weithin als Vater des gesamten Forschungsfelds der Softwareevolution. Als er 2010 starb, würdigte ihn die akademische Gemeinschaft genau so.

Eine Feinheit ist wichtig, bevor wir weitergehen, denn genau hier werden die meisten oberflächlichen Zusammenfassungen ungenau. Lehman behauptete nicht, dass diese Gesetze für jede Software gelten. Er teilte Programme in drei Typen ein, die SPE-Klassifikation:

• S-Type-Programme sind vollständig durch eine feste Spezifikation definiert. Eine Funktion, die ein mathematisches Ergebnis berechnet, ist korrekt oder inkorrekt gegenüber dieser Spezifikation, Punkt. Sie muss sich nie ändern.
• P-Type-Programme lösen ein reales Problem mit einer näherungsweisen Lösung (denk an eine Schach-Engine), bei der das Problem stabil ist, unsere Lösung sich aber immer verbessern lässt.
• E-Type-Programme sind in die reale Welt eingebettet. Sie mechanisieren eine menschliche oder geschäftliche Tätigkeit und werden Teil der Welt, die sie modellieren. Eine Banking-Plattform, ein E-Commerce-Checkout, ein Krankenhaus-Informationssystem. In dem Moment, in dem sie live gehen, verändern sie die Umgebung, was die Anforderungen verändert, was die Software erneut zur Änderung zwingt.

Die acht Gesetze beschreiben E-Type-Systeme, und fast alles, was du beruflich auslieferst, ist E-Type. Deshalb fühlen sich diese Gesetze persönlich an.

Die acht Gesetze der Softwareevolution auf einen Blick

Die Gesetze sind auch keine acht unzusammenhängenden Fakten. Sie verstärken einander zu einer einzigen Dynamik, die ein System in Richtung Verfall drängt, und einer einzigen Gegenkraft, die ihn aufhält:

Wie sich die Gesetze aufschaukeln: Rote Kanten treiben in Richtung Verfall, der grüne Pfad ist der gezielte Aufwand, der ihn aufhält.

Gesetz 1: Kontinuierlicher Wandel

“Ein E-Type-System muss kontinuierlich angepasst werden, sonst wird es zunehmend unbefriedigender.”

Das ist das Fundament. Der Wert eines E-Type-Programms ist nicht fix; er ist relativ zu einer sich bewegenden Umgebung definiert. Halte die Software still, und die Lücke zwischen dem, was sie tut, und dem, was die Welt braucht, weitet sich von selbst.

Praxisszenario. Deine E-Commerce-App ist an ein Payment-Gateway angebunden. Du hast diese Integration vor zwei Jahren geschrieben, und sie hat tadellos funktioniert, niemand hat sie angefasst. Dann kündigt das Gateway an, in 90 Tagen die Unterstützung für TLS 1.1 einzustellen und sein Webhook-Signaturformat zu ändern. Du hast null Bugs geschrieben, und doch ist dein “fertiges” Feature jetzt ein Countdown bis zu einem Produktionsausfall. Kontinuierlicher Wandel bedeutet, dass kein Modul jemals wirklich fertig ist; es ist nur vorerst fertig. Die ingenieurtechnische Antwort lautet: Budget für Wartung einplanen, die du noch nicht benennen kannst, und Integrationspunkte (Adapter, versionierte Schnittstellen) so gestalten, dass “die Welt hat sich bewegt” dich eine kleine Änderung statt einer Neuentwicklung kostet.

Gesetz 2: Zunehmende Komplexität

“Während ein E-Type-System sich entwickelt, steigt seine Komplexität, sofern nicht ausdrücklich daran gearbeitet wird, sie zu erhalten oder zu reduzieren.”

Achte auf die Formulierung: Komplexität steigt standardmäßig. Sie ist die natürliche Entropie eines Systems unter ständigem Wandel. Jedes unter Termindruck hinzugefügte Feature, jeder Sonderfall, der an einen bestehenden Ablauf geschraubt wird, jedes “das räumen wir später auf” erhöht die strukturelle Unordnung. Komplexität zu reduzieren ist das Einzige, was gezielten Aufwand erfordert, und dieser Aufwand steht selten auf der Roadmap.

Praxisszenario. Der Checkout eines Start-ups beginnt als eine saubere Funktion. Das Marketing will einen Pfad für Promo-Codes, also kommt ein if hinzu. Dann ein B2B-Rechnungspfad. Dann ein Geschenkkarten-Pfad. Dann regionale Steuerausnahmen. Achtzehn Monate später ist diese Funktion 600 Zeilen lang mit 40 interagierenden Flags, und jede Änderung riskiert, einen Pfad zu zerstören, an den sich niemand erinnert. Gesetz 2 sagt dir: Das war kein Versagen der Disziplin eines schlechten Entwicklers, es ist der erwartete Verlauf. Die Gegenmaßnahme besteht darin, Refactoring als wiederkehrenden Posten zu behandeln, nicht als heroische Einmalaktion: ein stehendes “Komplexitätsbudget” (etwa 15–20 % jedes Sprints), das man darauf verwendet, Module herauszulösen, tote Zweige zu löschen und die zyklomatische Komplexität im Zaum zu halten. Microservice-Grenzen und Clean-Architecture-Nahtstellen sind Taktiken, aber der strategische Punkt ist einfacher: wenn du keine Energie in den Kampf gegen Komplexität steckst, gewinnt die Komplexität. (Genau das nennt Lean Thinking Verschwendung eliminieren: Komplexität, die ihren Nutzen nicht mehr rechtfertigt, ist muda, und sie zurückzuschneiden ist echte Arbeit, kein Overhead.)

Gesetz 3: Selbstregulierung

“Die Evolutionsprozesse von E-Type-Systemen sind selbstregulierend, wobei die Verteilung der Produkt- und Prozessmaße nahe an der Normalverteilung liegt.”

Das ist das in Zusammenfassungen am häufigsten verstümmelte Gesetz (es geht nicht um die “Evolution großer Programme”). Lehman beobachtete, dass sich die Evolution eines Systems wie ein regulierter Organismus verhält. Maße wie Release-Größe und Wachstumsrate schwanken um einen stabilen Trend, wobei sich Ausschläge nach oben und unten in etwa ausgleichen. Drückst du in einem Release hart, neigt das System zur Kompensation: ein Rückkopplungsmechanismus zieht es zurück zu seiner langfristigen Rate.

Praxisszenario. Ein Produktmanager, frustriert über den stetigen Fortschritt, ordnet ein Blockbuster-Release an: das Dreifache des üblichen Umfangs in einem Quartal. Das Team gehorcht. Das Ergebnis ist für jeden, der dieses Gesetz kennt, vorhersehbar: die Fehlerzahlen schnellen hoch, das folgende Release schrumpft dramatisch, während das Team die Nachwirkungen verarbeitet, und der Durchschnitt der beiden Releases landet fast genau auf der historischen Trendlinie. Die umsetzbare Erkenntnis ist ein Geschenk für Planer: Deine eigene Release-Historie ist ein Prognosewerkzeug. Wenn deine letzten zehn Releases im Schnitt rund 30 Story Points an neuer Netto-Funktionalität mit einem in etwa normalverteilten Fehleranfall lieferten, kämpft ein Plan, der 90 annimmt, gegen die Schwerkraft. Nutze den Trend, um glaubwürdige Erwartungen zu setzen, und behandle ein Release, das ihn wild übertrifft, als Risikosignal, nicht als Triumph.

Gesetz 4: Erhaltung der organisatorischen Stabilität

“Die durchschnittliche effektive globale Aktivitätsrate in einem sich entwickelnden E-Type-System ist über die Lebensdauer des Produkts invariant.”

Die effektive Rate, mit der nützliche Veränderung ausgeliefert wird, bleibt über die Lebensdauer eines Projekts tendenziell ungefähr konstant, und ist, bemerkenswerterweise, weitgehend unabhängig von den Ressourcen, die du darauf wirfst. Das ist das Gesetz, das sich mit Fred Brooks’ berühmter Beobachtung in The Mythical Man-Month überschneidet, dass “das Hinzufügen von Arbeitskräften zu einem verspäteten Softwareprojekt es noch später macht”.

Praxisszenario. Ein Projekt liegt drei Monate hinter dem Plan. Der Instinkt der Führung ist es, fünf Entwickler hinzuzunehmen. Doch die neuen Leute müssen die Domäne lernen, das bestehende Team muss aufhören zu bauen, um sie einzuarbeiten, und die Zahl der Kommunikationspfade im Team wächst quadratisch (ein Fünf-Personen-Team hat 10 paarweise Verbindungen; ein Zehn-Personen-Team hat 45). In den nächsten zwei Monaten sinkt der effektive Output. Die Erhaltung der organisatorischen Stabilität besagt, dass der Durchsatz weniger von der Teamgröße bestimmt wird als von der angesammelten Komplexität des Systems und der Kommunikationsstruktur der Organisation. Der Hebel sind nicht mehr Leute, sondern das Beseitigen von Reibung: Build- und Deploy-Zeiten verkürzen, die Komplexität aus Gesetz 2 abbauen, Verantwortlichkeiten klären und Feedback-Latenzen verkürzen, damit die effektive Rate jedes Entwicklers steigt.

Gesetz 5: Erhaltung der Vertrautheit

“Während ein E-Type-System sich entwickelt, müssen alle damit Verbundenen (Entwickler, Vertriebsmitarbeiter, Nutzer) die Beherrschung seines Inhalts und Verhaltens aufrechterhalten, um eine zufriedenstellende Evolution zu erreichen. Übermäßiges Wachstum schmälert diese Beherrschung. Daher bleibt das durchschnittliche inkrementelle Wachstum invariant, während das System sich entwickelt.”

Alle, die mit dem System verbunden sind (Entwickler, Betreiber, Support-Personal und Nutzer), können pro Release nur ein gewisses Maß an Veränderung aufnehmen, bevor sie den Überblick darüber verlieren, wie es funktioniert. Releases, die zu viel Neues hineinpacken, sprengen dieses Aufnahmebudget, und Qualität und Akzeptanz leiden darunter.

Praxisszenario. Ein Team versucht eine “Big-Bang”-Neuentwicklung: ein Jahr Arbeit, dann ein einzelnes Release, das 70 % des Produkts auf einen Schlag ersetzt. Beim Launch fluten die Support-Tickets herein, das Team kann nicht nachvollziehen, welche der tausend Änderungen welche Regression verursacht hat, und Power-User rebellieren gegen eine Oberfläche, die sie nicht mehr wiedererkennen. Gesetz 5 erklärt die gescheiterten UI-Redesigns, an die wir uns alle erinnern, jene, bei denen Nutzer Petitionen starteten, um die alte Version zurückzubekommen. Die Disziplin, die es vorschreibt, besteht darin, die Neuartigkeit jedes Releases zu deckeln, nicht nur seine Größe. Liefere kontinuierlich in verdaulichen Inkrementen aus, betreibe neue und alte Pfade hinter Flags nebeneinander und gib den Leuten Zeit, Vertrautheit aufzubauen. Die Veränderung, die dein Team und deine Kunden verstehen können, ist die eigentliche Beschränkung, nicht die Veränderung, die du coden kannst.

Gesetz 6: Kontinuierliches Wachstum

“Der funktionale Umfang eines E-Type-Systems muss kontinuierlich erhöht werden, um die Nutzerzufriedenheit über seine Lebensdauer aufrechtzuerhalten.”

Hier kommt das am häufigsten verwechselte Trio der ganzen Sammlung, trennen wir es also sauber. Bei Gesetz 1 (Wandel) geht es darum, bestehende Funktionalität an eine sich verschiebende Welt anzupassen. Bei Gesetz 2 (Komplexität) geht es um interne Unordnung, die sich ansammelt. Bei Gesetz 6 (Wachstum) geht es darum, dass die externe Feature-Oberfläche sich ausweiten muss, weil die Nutzererwartungen unaufhörlich nach oben klettern und sich nie zurücksetzen. Das entzückende Extra von gestern ist die selbstverständliche Grundannahme von heute.

Praxisszenario. Ein SaaS-Analytics-Produkt startet mit fünf Integrationen, und die Kunden lieben es. Zwei Jahre später springen Interessenten in Vertriebsgesprächen ab, weil ihm der Snowflake-Konnektor fehlt, den ein Wettbewerber letzten Monat hinzugefügt hat. Das Produkt ist nicht schlechter geworden: sein funktionaler Umfang hörte schlicht auf zu wachsen, während die Erwartungen weiter stiegen, und die Lücke liest sich als Niedergang. Gesetz 6 ist der Motor hinter jeder Produkt-Roadmap und jeder Liste von “Table-Stakes”-Features. Der strategische Haken ist, dass Wachstum (Gesetz 6) und Komplexität (Gesetz 2) gegeneinander ziehen: Jedes Feature, das du zur Zufriedenstellung der Nutzer hinzufügst, erhöht auch die Entropie. Reife Teams behandeln dies als expliziten Trade-off und schneiden Features mit geringem Nutzen ebenso konsequent zurück, wie sie solche mit hohem Nutzen hinzufügen, damit Wachstum die Codebasis nicht heimlich verpfändet.

Gesetz 7: Nachlassende Qualität

“Die Qualität eines E-Type-Systems wird scheinbar nachlassen, sofern es nicht rigoros gepflegt und an Veränderungen der Betriebsumgebung angepasst wird.”

Beachte das präzise Wort: Qualität wird scheinbar nachlassen. Der Code auf der Platte hat sich nicht geändert, aber die Maßstäbe, an denen er gemessen wird, schon. Die Umgebung hat sich bewegt (neue Browser, neue Geräte, die zehnfache Last, neue Sicherheitserwartungen) und ein Programm, das gegen den Maßstab von 2019 exzellent war, sieht gegen den von 2026 schäbig aus.

Praxisszenario. Ein Monolith läuft seit Jahren zuverlässig. Niemand hat einen Bug eingeführt. Trotzdem beschweren sich Nutzer jetzt, er sei “langsam und klobig”. Was tatsächlich passiert ist: Der Mobile-Traffic stieg von 20 % auf 70 %, und die App war nie dafür ausgelegt; der Datenbestand wuchs um das 50-Fache, und Abfragen, die sofort waren, kriechen jetzt; Wettbewerber haben einen neuen Maßstab für Reaktionsfähigkeit gesetzt. Nachlassende Qualität besagt, dass das Gegenmittel aktiv ist, nicht reaktiv: du musst dich kontinuierlich an die Betriebsumgebung anpassen, nicht nur gemeldete Defekte beheben. Praktisch heißt das: Observability, die reale Performance gegen die heutigen Erwartungen verfolgt, regelmäßige Neukalibrierung von Last und Sicherheit sowie automatisierte Tests plus CI/CD-Pipelines, die kontinuierliche Anpassung billig genug machen, um sie tatsächlich zu betreiben. Qualität ist kein Zustand, den man erreicht; sie ist eine Rate, die man aufrechterhält.

Gesetz 8: Rückkopplungssystem

“E-Type-Evolutionsprozesse bilden mehrstufige Rückkopplungssysteme mit mehreren Schleifen und mehreren Akteuren.”

Das ist der Schlussstein, und er rahmt alle anderen neu ein. Ein großes System weiterzuentwickeln ist keine lineare Pipeline von der Anforderung zum Code. Es ist ein Geflecht aus Rückkopplungsschleifen: Nutzer reagieren auf Releases, Support-Daten fließen zum Produkt, Produktentscheidungen schränken die Entwicklung ein, die Realität der Entwicklung formt die Roadmap um, die Organisationsstruktur prägt die Architektur (Conway’s Law lauert in der Nähe). Weil die Schleifen interagieren, erzeugen lokale Änderungen nicht-lokale, oft kontraintuitive Effekte.

Die äußere Lieferschleife plus die gestrichelten inneren korrigierenden Schleifen: du steuerst sie alle gleichzeitig, niemals eine isoliert.

Praxisszenario. Ein VP, der die Qualität heben will, ordnet eine neue Regel an: Jeder Pull Request braucht drei Freigaben. Die beabsichtigte Schleife sagt “mehr Review → weniger Bugs”. Das tatsächliche System sagt etwas anderes: Die Review-Warteschlangen stauen sich, Entwickler bündeln größere PRs, um den Overhead zu amortisieren, große PRs werden durchgewinkt, weil niemand 2.000 Zeilen sorgfältig prüfen kann, und die Fehlerraten steigen. Gesetz 8 warnt davor, dass man ein Rückkopplungssystem nicht zuverlässig steuern kann, indem man an einer Variable dreht und annimmt, der Rest bliebe still. Die Disziplin, die es verlangt, ist Demut plus Messung: Ändere eine Sache, instrumentiere die Schleifen, achte auf Effekte zweiter Ordnung und passe an, genau die empirische, hypothesengetriebene Haltung, die gute DevOps- und kontinuierliche Verbesserungskulturen verkörpern.

Wo die Gesetze sich verbiegen, und warum das der nützlichste Teil ist

Eine 50 Jahre alte Theorie, die auf einem Mainframe der 1960er-Jahre fußt, verdient kritische Prüfung, und sie hat reichlich davon erhalten. Die wichtigste Herausforderung kam aus der Open-Source-Welt.

Im Jahr 2000 untersuchten Michael Godfrey und Qiang Tu den Linux-Kernel über 96 Releases von 1994 bis 2000 und fanden etwas, das die Gesetze nicht vorhergesagt hatten: Der Kernel wuchs mit einer superlinearen Rate. Das widersprach direkt dem Wachstumsmodell mit umgekehrt quadratischem Verlauf, das Lehman und Turski aus kommerziellen Systemen abgeleitet hatten, bei denen erwartet wurde, dass sich das Wachstum verlangsamt, weil Größe und Komplexität jede Änderung schwieriger machen. Ein massiv paralleles, global verteiltes, ehrenamtliches Entwicklungsmodell schrieb die Wachstumskurve offenbar neu. Spätere Studien zu langlebiger Open-Source-Software fanden, dass die Gesetze ungleichmäßig gelten: Kontinuierlicher Wandel erweist sich als bemerkenswert robust, doch andere (die Erhaltung der Vertrautheit und die vorhergesagte Wachstumsdynamik selbst) greifen oft nicht mehr, sobald sich der Kontext eines Projekts verschiebt (zum Beispiel, wenn es in eine Wartungsphase eintritt oder durch massiv parallele Mitwirkung wächst).

Warum verbiegen sich die Gesetze genau hier? Die Abweichung ist nicht zufällig: sie geht auf viele Faktoren zurück, und der erste davon ist, dass die Kräfte, die das Funktionswachstum antreiben, nicht dieselben sind. Lehman leitete seine Gesetze aus kommerziellen Systemen ab, bei denen das, was gebaut wird, letztlich vom Markt bestimmt wird: Features werden hinzugefügt, um Deals zu gewinnen, Kunden zu halten und Umsatz zu schützen, und dieser ökonomische Druck prägt Release-Kadenz, Umfang und das ständige Tauziehen zwischen neuer Funktionalität und Stabilität. Ein Open-Source-Kernel folgt einem völlig anderen Satz von Anreizen. Ein Feature landet in Linux, weil ein Mitwirkender es für seine eigene Hardware braucht, weil ein Hersteller einen Treiber upstreamt, weil Maintainer es für technisch fundiert und die langfristige Wartungslast wert halten, nicht, weil es eine Umsatzkennzahl bewegt oder auf einer Vertriebs-Roadmap auftaucht. Es gibt kein Quartalsziel zu erreichen, keine Churn-Metrik im Blick zu behalten, keine Preisstufe zu schützen. Und mit Tausenden unabhängiger Mitwirkender, die parallel jeweils ihr eigenes Anliegen verfolgen, wird das Wachstum nicht durch die Kapazität einer einzelnen Organisation (Gesetz 4) oder durch das, womit ein Team vertraut bleiben kann (Gesetz 5), gedrosselt, sodass es superlinear verlaufen kann, auf eine Weise, die Lehmans kommerzielle Datensätze nie zeigten. Die Kriterien, die überhaupt darüber entscheiden, ob ein Feature existiert, unterscheiden sich schlicht von den kommerziellen, auf die die Gesetze kalibriert wurden.

Das rahmt das gesamte Ergebnis neu ein. Mehrere von Lehmans Gesetzen sind im Kern ebenso Aussagen über die Organisation, die die Software produziert (ihre Ökonomie, ihre Kapazität, ihre Anreize), wie über den Code selbst. Ändere den Antrieb, der die Arbeit vorantreibt, und das messbare Verhalten ändert sich mit ihm. Der Linux-Kernel brach die Gesetze nicht; er lief auf einem anderen Antrieb als dem, den Lehman beobachtete.

Das ist kein Grund, die Gesetze zu verwerfen. Es ist der Grund, sie zu respektieren. Lehmans Gesetze sind empirische Verallgemeinerungen über ein bestimmtes Regime: geschlossene, kommerziell entwickelte, organisatorisch begrenzte Systeme. Wenn du das Regime grundlegend änderst (die Ökonomie, die Parallelität, das Mitwirkungsmodell), verbiegen sich einige Gesetze und andere brechen. Zu wissen, welche Gesetze robust sind (Wandel ist unvermeidlich, Komplexität steigt ohne Aufwand, Rückkopplung dominiert) und welche bedingt sind (die exakte Wachstumskurve, die selbstregulierende Kadenz), ist genau die Art von Urteilsvermögen, die Ingenieure, die Prinzipien zitieren, von Ingenieuren trennt, die sie anwenden.

Die eine Idee, die du behalten solltest

Streift man die Förmlichkeit ab, kollabieren die acht Gesetze zu einer einzigen, unbequemen Wahrheit:

Sich selbst überlassen, gerät es aus dem Takt mit der Welt (Gesetz 1), sammelt interne Unordnung an (Gesetz 2), sieht gegenüber steigenden Maßstäben schlechter aus (Gesetz 7) und enthält seinen Nutzern das Wachstum vor, das sie inzwischen erwarten (Gesetz 6), während Rückkopplungsschleifen, die du nicht vollständig kontrollierst (Gesetz 8), deinen Versuchen widerstehen, es zu managen, und du dich mit schierer Teamgröße nicht freikaufen kannst (Gesetz 4).

Die Teams, die gedeihen, sind nicht jene, die diesen Kräften entkommen, das schafft niemand. Es sind jene, die für sie planen: die Budget für Wartung einplanen, bevor sie dringend wird, die kontinuierlich Aufwand in den Kampf gegen Komplexität stecken, die jedes Release auf das zuschneiden, was Menschen aufnehmen können, die Qualität als aufrechtzuerhaltende Rate statt als Ziellinie behandeln und die ihren Prozess steuern, indem sie seine Schleifen messen, statt Anordnungen in sie hineinzurufen.

Für diese Haltung gibt es einen Namen. Wenn Lehmans Gesetze die Krankheit beschreiben (Entropie, die sich ansammelt, Komplexität, die von selbst wächst, Qualität, die abrutscht, während die Welt sich weiterbewegt), dann ist Lean Thinking das Naheliegendste, was wir an einer Behandlung haben: unermüdlich Verschwendung (muda) beseitigen, Batch-Größen klein halten, damit Menschen den Überblick über das System nie verlieren (was genau Lehmans Erhaltung der Vertrautheit ist), Qualität einbauen, statt sie nachträglich herauszuprüfen, und Rückkopplungsschleifen (nicht Erlasse) die Arbeit lenken lassen (Lehmans Achtes Gesetz, neu formuliert als Managementpraxis). Es ist keine erzwungene Analogie: Die beiden Rahmenwerke beschreiben dasselbe System von entgegengesetzten Enden: das eine benennt die Kräfte, das andere die Disziplin, die ihnen begegnet.

Der Begleiter zu diesem Artikel

Lean Thinking for Busy Software Developers

Lehmans Gesetze benennen die Kräfte, die jede Codebasis in Richtung Verfall ziehen. Dieses Buch ist das Feldhandbuch, um gegenzusteuern. Es überträgt Toyotas Lean-Prinzipien auf die Codebasis: die unsichtbare Verschwendung in deinem Prozess beseitigen, Batches klein halten (Erhaltung der Vertrautheit in der Praxis), Qualität einbauen, statt sie nachträglich herauszuprüfen, und mit Rückkopplungsschleifen statt mit Erlassen steuern, mit konkreten Beispielen, DORA-Metriken und einem ganzen Kapitel über die Arbeit mit KI-Agenten.

Auf Leanpub kaufen → Mehr erfahren

Derzeit auf Italienisch; eine englische Ausgabe ist in Arbeit, melde dich auf Leanpub an, um benachrichtigt zu werden.

Lehman sah zu, wie ihm ein Mainframe-Betriebssystem in den 1970er-Jahren diese Lektionen beibrachte. Deine verteilte, cloud-native, KI-gestützte Codebasis bringt sie dir gerade jetzt erneut bei. Die einzige Frage ist, ob du den Lehrplan liest oder in einer Prüfung benotet wirst, von der du nicht wusstest, dass du sie ablegst.

Die wichtigsten Erkenntnisse

• Verfall ist die Voreinstellung. Ein reales (E-Type-)System, das man unangetastet lässt, bleibt nicht still: es gerät aus dem Takt mit seiner Umgebung (Gesetz 1) und scheint an Qualität zu verlieren (Gesetz 7).
• Komplexität wächst, sofern du sie nicht bekämpfst. Zunehmende Komplexität (Gesetz 2) ist Entropie; nur gezieltes Refactoring kehrt sie um. Plane Budget dafür ein, hoffe nicht darauf.
• Du kannst dich nicht mit Teamgröße freikaufen. Die Erhaltung der organisatorischen Stabilität (Gesetz 4) und Brooks’ Gesetz bedeuten, dass der Durchsatz von Komplexität und Kommunikation bestimmt wird, nicht von der schieren Mitarbeiterzahl.
• Liefere Veränderung aus, die Menschen aufnehmen können. Die Erhaltung der Vertrautheit (Gesetz 5) deckelt, wie viel Neues ein Team und seine Nutzer pro Release vertragen. Kleine Batches schlagen Big-Bang-Neuentwicklungen.
• Wachse weiter, aber schneide zurück. Kontinuierliches Wachstum (Gesetz 6) ist für die Zufriedenheit zwingend, doch jedes Feature erhöht die Komplexität, behandle es also als expliziten Trade-off.
• Steuere die Schleifen, nicht die Variablen. Evolution ist ein Rückkopplungssystem (Gesetz 8); ändere eine Sache, miss die Effekte zweiter Ordnung und passe an.
• Die Gesetze verbiegen sich, also nutze Urteilsvermögen. Sie gelten ungleichmäßig über moderne und Open-Source-Projekte hinweg: wisse, welche robust und welche bedingt sind.

Häufig gestellte Fragen

Was sind Lehmans Gesetze der Softwareevolution?

Es sind acht empirische Beobachtungen, formuliert von Meir M. Lehman zwischen 1974 und 1996, die beschreiben, wie E-Type-Softwaresysteme (also solche, die in die reale Welt eingebettet sind) sich im Laufe der Zeit unweigerlich verändern, wachsen und verfallen, sofern nicht gezielt Aufwand investiert wird. Die Sammlung umfasst Kontinuierlichen Wandel, Zunehmende Komplexität, Selbstregulierung, Erhaltung der organisatorischen Stabilität, Erhaltung der Vertrautheit, Kontinuierliches Wachstum, Nachlassende Qualität und Rückkopplungssystem.

Was ist ein E-Type-System?

In Lehmans SPE-Klassifikation ist ein E-Type-Programm eines, das in die reale Welt eingebettet ist und eine menschliche oder geschäftliche Tätigkeit mechanisiert, etwa eine Banking-Plattform oder ein E-Commerce-Checkout. Anders als S-Type-Programme (durch eine feste Spezifikation definiert) und P-Type-Programme (eine näherungsweise Lösung für ein stabiles Problem) verändert ein E-Type-System genau die Umgebung, die es modelliert, was es zur ständigen Weiterentwicklung zwingt. Die acht Gesetze beschreiben E-Type-Systeme.

Gelten Lehmans Gesetze auch heute noch für moderne und Open-Source-Software?

Teilweise. Replikationsstudien haben gezeigt, dass die Gesetze ungleichmäßig gelten. Kontinuierlicher Wandel ist bemerkenswert robust, doch andere verbiegen sich, sobald sich das Entwicklungsregime ändert. Godfreys und Tus Studie zum Linux-Kernel aus dem Jahr 2000 stellte superlineares Wachstum fest, das dem Wachstumsmodell mit umgekehrt quadratischem Verlauf widersprach, das Lehman aus kommerziellen Systemen abgeleitet hatte. Spätere FLOSS-Studien fanden, dass Gesetze wie die Erhaltung der Vertrautheit häufig nicht greifen.

Warum scheint die Softwarequalität selbst dann zu sinken, wenn niemand den Code ändert?

Wegen Lehmans Siebtem Gesetz, der Nachlassenden Qualität: Die Qualität eines E-Type-Systems wird an einer sich bewegenden Umgebung gemessen. Während Browser, Geräte, Lastvolumen und Nutzererwartungen voranschreiten, wirkt unveränderte Software zunehmend schlechter, obwohl sich ihr Code nie geändert hat. Das Gegenmittel ist kontinuierliche Anpassung an die Betriebsumgebung, nicht bloß reaktives Bugfixing.

Warum folgt der Linux-Kernel nicht Lehmans Wachstumsgesetz?

Weil der Kernel anderen Anreizen folgt als die kommerziellen Systeme, die Lehman untersuchte. Sein Wachstumsmodell setzte voraus, dass das Funktionswachstum von Markt- und Umsatzdruck innerhalb einer einzelnen Organisation mit begrenzter Kapazität bestimmt wird. In Open Source werden Funktionen hinzugefügt, weil Mitwirkende sie für ihre eigene Hardware brauchen, weil Hersteller Treiber upstreamen oder weil Maintainer sie für technisch fundiert halten, nicht um ein Umsatzziel oder eine Vertriebs-Roadmap zu treffen. Mit Tausenden unabhängiger Mitwirkender, die parallel arbeiten, wird das Wachstum nicht durch die Kapazität einer einzelnen Organisation gedrosselt, weshalb Godfrey und Tu (2000) superlineares Wachstum statt der vorhergesagten Verlangsamung maßen. Das Gesetz scheiterte nicht; der Kernel läuft auf einem anderen Antrieb, weil die Kriterien, die darüber entscheiden, ob eine Funktion existiert, sich von den kommerziellen unterscheiden, auf die die Gesetze kalibriert wurden.

Quellen und weiterführende Literatur: Bélády & Lehman, “A Model of Large Program Development,” IBM Systems Journal (1976); Lehman, “Laws of Software Evolution Revisited” (1996); Godfrey & Tu, “Evolution in Open Source Software: A Case Study” (2000); Canfora et al., “In memory of Manny Lehman, ‘Father of Software Evolution’” (2011); und González-Barahona et al., “Studying the laws of software evolution in a long-lived FLOSS project” (2014).