Letztes Jahr, Mandat bei einem Maschinenbauer in Baden-Württemberg, 85 Mitarbeitende, Auftragsfertigungssoftware selbst entwickelt. Der Lead-Developer — er macht das seit 14 Jahren, kennt das System in- und auswendig — zeigt mir stolz eine OrderHelper-Klasse. 2.300 Zeilen. 47 Methoden. 19 Boolean-Parameter in der zentralen Validierungsfunktion. Ich frage: "Wann hat das angefangen?" Er denkt kurz nach. "Wir wollten halt nicht alles doppelt schreiben."
Das ist kein Einzelfall. Das ist das Standardmuster, das ich in jedem dritten KMU-Mandat antreffe, wenn das Dev-Team zwischen zwei und fünf Personen groß ist und länger als fünf Jahre an derselben Codebase arbeitet. Die Intention war sauber. Das Ergebnis ist ein Albtraum.
Was Milan Jovanović sagt — und er hat recht
Jovanović legt in seinem Artikel präzise den Finger in die Wunde: DRY wird von den meisten Entwicklern als "kein Copy-Paste" verstanden, obwohl die Originalformulierung aus dem Pragmatic Programmer etwas grundlegend anderes meint — nämlich, dass Wissen (nicht Code) eine einzige, autoritative Quelle haben soll. Zwei identisch aussehende Code-Schnipsel können komplett unterschiedliches Domänenwissen repräsentieren. Wenn du sie zusammenfasst, klebst du zwei unabhängige Konzepte zusammen — und zahlst das mit Boolean-Flags, die sich über Jahre akkumulieren.
Sein praktisches Kriterium: Erst beim dritten Mal abstrahieren, und dann nur, wenn man die Abstraktion nach einem echten Domänenkonzept benennen kann. "Helper", "Utils" oder "ProcessData" sind Warnsignale. "TaxRate", "InvoiceNumber" oder "ShippingAddress" sind legitime Kandidaten. Der vollständige Original-Beitrag von Milan Jovanović: DRY Is the Most Misunderstood Rule in Programming
Das ist saubere Argumentation, und ich unterschreibe jeden Satz davon.
Wie das im KMU wirklich landet
Hier fängt der Teil an, den Jovanović — aus seiner .NET-Enterprise-Welt heraus — nicht beleuchtet. Nicht weil er ihn nicht kennt, sondern weil er einfach nicht sein Publikum ist.
Im KMU fehlt die Architektur-Review-Kultur, bevor das Problem entsteht.
Jovanović schreibt über Modular Monoliths, Bounded Contexts, Vertical Slices. Das sind Konzepte, die voraussetzen, dass jemand im Team aktiv über Architektur nachdenkt. In einem Betrieb mit zwei Entwicklern, von denen einer eigentlich der IT-Leiter ist und nebenbei noch den Exchange-Server betreut, findet dieses Gespräch nicht statt. Der Code wächst organisch. DRY wird nicht als architektonisches Prinzip angewendet, sondern als reflexartige Reaktion auf Redundanz — weil es sich einfach falsch anfühlt, denselben Code zweimal zu schreiben.
Das Ergebnis ist nicht ein falsch angewendetes Prinzip. Das Ergebnis ist ein System, das nach außen DRY aussieht und innen eine einzige große implizite Abhängigkeit ist.
Der Boolean-Parameter-Effekt ist im KMU besonders heimtückisch.
In einem Enterprise-Projekt mit CI/CD, Codereviews und mindestens einem Senior, der "Nein" sagen darf, wird die wachsende Boolean-Hölle irgendwann geblockt. Im KMU nicht. Da wächst die ValidateOrder(bool isExport, bool hasCustomerDiscount, bool requiresApproval, bool isReturnOrder)-Signatur über Jahre hinweg, weil niemand Zeit hat, die technische Schuld anzugehen — und weil der einzige, der das System versteht, genau der ist, der die Flags eingebaut hat.
Die Kosten entstehen dann, wenn dieser Entwickler das Unternehmen verlässt. Oder wenn ein zweiter Entwickler eingearbeitet werden soll. Ich schätze konservativ: drei bis sechs Monate Onboarding-Zeit gehen allein für das Verstehen solcher gewachsenen Strukturen drauf. Das ist echtes Geld — bei einem Junior-Entwickler mit 50.000 EUR Jahresgehalt sind das 12.500 bis 25.000 EUR an Produktivitätsverlust.
Die "Warte auf das dritte Mal"-Regel funktioniert nur mit Disziplin — und die ist im Tagesgeschäft knapp.
Jovanović empfiehlt, erst beim dritten identischen Vorkommen zu abstrahieren. Das ist handwerklich richtig. Aber in einem KMU-Dev-Team ohne dedizierte Architektur-Zeit landet diese Regel im besten Fall als gut gemeinter Vorsatz, der in der nächsten Sprint-Woche vergessen wird. Das Problem ist nicht fehlendes Wissen — die meisten Entwickler, mit denen ich arbeite, haben das Konzept schon mal gehört. Das Problem ist fehlende Struktur, die erlaubt, dieses Wissen anzuwenden.
Was ich meinen Mandanten konkret empfehle
Drei Dinge, die im KMU-Kontext tatsächlich wirken:
1. Einmal im Quartal eine "Abstractions-Retrospektive" — 60 Minuten, nicht mehr.
Kein großes Architektur-Meeting. Nur eine ehrliche Frage: Welche Methode, welche Klasse, welches Modul macht uns seit drei Monaten nervös? Was würden wir nicht mehr anfassen, wenn wir könnten? Das reicht, um die schlimmsten Zeitbomben zu identifizieren, bevor sie explodieren.
2. Der Boolean-Flag-Test als Merge-Kriterium.
Jede neue Boolean-Parameter-Ergänzung an einer bestehenden Methode triggert automatisch eine kurze Diskussion: Ist das wirklich dasselbe Konzept, oder haben wir gerade zwei Dinge zusammengeklebt, die zufällig ähnlich aussehen? Dieser Test kostet fünf Minuten und verhindert, dass sich technische Schuld still akkumuliert.
3. Domänen-Nomenklatur vor Code-Nomenklatur.
Wenn ein Entwickler eine neue Abstraktion einführen will und sie nicht nach einem Begriff aus dem Geschäftsvokabular benennen kann — also nach einem Begriff, den auch der Auftragsbearbeiter oder der Buchhalter kennt —, dann ist das ein Zeichen, dass die Abstraktion vermutlich Codeform, nicht Domänenwissen konserviert. Das lässt sich als einfache Frage formulieren: "Würde [Name der Fachkraft im Unternehmen] diesen Begriff verstehen?"
Die eigentliche Lektion für den Mittelstand
Jovanović beschreibt das Problem korrekt und gibt die richtige Lösung. Was er nicht beschreibt, ist der Kontext, in dem dieses Problem im KMU entsteht: nicht aus Dummheit oder Nachlässigkeit, sondern aus permanentem Zeitdruck, kleinen Teams ohne Peer-Review-Kultur, und dem grundmenschlichen Wunsch, ordentlich zu arbeiten — der dann in die falsche Richtung kanalisiert wird.
Die wichtigste Empfehlung, die ich gebe: Macht DRY zu einem expliziten Gesprächsthema, nicht zu einer impliziten Annahme. Die meisten Teams, mit denen ich arbeite, haben nie aktiv entschieden, wie sie mit Abstraktion umgehen wollen. Sie haben es einfach gemacht — jeder nach seinem Bauchgefühl. Das Ergebnis ist eine Codebase, die aus einer Sammlung von persönlichen Bauchgefühlen besteht.
Dreißig Minuten Gespräch über "wann abstrahieren wir, wann nicht" sparen erfahrungsgemäß Wochen an Maintenance-Zeit im Jahr darauf. Das ist keine Theorie — das ist, was ich in den letzten Mandaten gemessen habe.
Wenn du wissen willst, wie das in deiner Codebase konkret aussieht und was sich lohnt anzugehen: → 30 Min Klartext-Sparring
— Bernhard