YAGNI! Das “You aren’t gonna need it!” aus dem eXtreme Programming hat schon immer zu vielen Diskussionen geführt.
Gerade in konservativen Unternehmen, die auf solide Softwareentwicklung setzen, werden Minimallösungen sehr kritisch betrachtet. Schnell wird in Wiederverwertbarkeit, Konfigurierbarkeit und sehr solide Lösungen investiert ohne genau das Endstadium zu kennen.
Ich sehe dies zunehmend kritischer.
Ich habe nichts gegen Qualität und gute Software. Ich habe allerdings etwas gegen Investitionen, die nie eine Rendite erwirtschaften.
In der Softwareentwicklung wird bei “Verschwendung” gerne auf die Implementierung von Features verwiesen, die (fast) nie benutzt werden. Zu selten werden jedoch auch die inneren Werte der Software kritisch hinterfragt. Häufig wir ausschließlich mit Beispielen argumentiert, in denen überhaupt keine Rücksicht auf die interne Struktur genommen wurde. Diese dienen dann als Begründung für umfangreiche Umbauarbeiten. Die Auswirkungen dieser Änderungen auf die Gesamtkosten wird dann häufig nicht mehr betrachtet.
Es ist doch meist so, dass ein Kunde für Features zahlt, die er beauftragt hat und dann nie nutzt. Für mögliche Verbesserungen an der internen Struktur der Software zahlt er typischerweise nicht, diese erwirtschaften eine Rendite, indem die Wartungskosten sinken. Leider ist dies zu häufig nicht der Fall.
Beispiel: “Wir mussten das konfigurierbar machen (1), da wir sonst bei jeder Änderung an der Darstellung der Seite drei weitere Dateien hätten anpassen (2) müssen!” ist eine typische Begründung von Entwicklern.
Meiner Meinung nach steckt hinter (1) oft der Spaß, etwas “solides” zu bauen. Hier ist der Ingenieur gefragt. “Wofür habe ich denn sonst studiert?”. Zudem kommt oft noch eine Brise Angst hinzu, sich bei einer einfachen Lösung später rechtfertigen zu müssen “(“Warum habt ihr nicht … ?”).
Bei (2) geht es darum etwas am Laufen zu halten. Ein pragmatischer Handwerker zimmert etwas zusammen. Die Aufgabe ist nicht sonderlich spannend und wir wissen alle, dass früher oder später etwas noch einmal angepasst werden muss. Leider ist dies auch oft die Quelle von Fehlern, die lange gesucht werden müssen – Fehler die entstehen, wenn man die “langweilige Handwerksarbeit” nicht sorgfältig durchführt.
Leider führt eben auch (1) oft zu hohen Folgekosten, beispielsweise wenn während einer Entwicklung etwas zu früh verallgemeinert wurde. Später werden weitere Aspekte hinzugefügt und die Annahmen für die Verallgemeinerung ändern sich. Das Konstrukt funktioniert nicht mehr, es muss angepasst und mit Balkonen versehen werden. Plötzlich wird aus einer soliden Ingenieursleistung eine immer weniger wartbare Ansammlung von Sonderfällen.
Code-Duplizierung doch nicht böse?
Vor diesem Hintergrund sehe ich Code-Duplizierung – gerade bei bestimmten Teilen von Webseiten in Portalprojekten – nicht immer kritisch. Solange es handhabbar bleibt, kann man (sollte man?!) die Entscheidung, was als Verallgemeinerung extrahiert werden soll, hinausschieben. Zu einem späteren Zeitpunkt, wenn sich die Anforderungen in dem betroffenen Teil der Anwendung wirklich nicht mehr im großen Umfang ändern, kann schließlich eine Verallgemeinerung vorgenommen werden.
