Verschwendung in der Softwareentwicklung

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.

image

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.

2 thoughts on “Verschwendung in der Softwareentwicklung

  1. Hallo Felix

    Die von dir geschilderten Aussagen kenne ich auch. Ich bin ähnlich wie du der Meinung, dass zu schnell, zu oft refactored wird und dabei ein notwendiger Prakmatismus vergessen wird. Denn der ROI ist doch eher zweifelhaft.
    Bei mir war es so, dass die Funktionalität für mich als PO ausreichend vorhanden war und dann die Aussage vom Team kam, die Item Done Regeln müssten noch umgesetzt werden. Dies würde aber im aktuellen Sprint nicht mehr reichen und ich soll es für den nächsten Sprint einplanen! Zuerst wollte ich dies nicht machen, denn für mich war die Funktionalität ausreichend umgesetzt und Qualitätsproblem konnte ich auch keine erkennen. Dann wurde ich darauf hingewiesen, dass ich dies so nicht ausliefern dürfte, denn schließlich ist das Item noch nicht done und bei TTD heißt es doch auch “make it run, make it right, make it fast”. Ich hab noch auf das Commitment hingewiesen das ich von ihnen bekommen habe, aber auch dies hat nicht geholfen.
    Ähnlich wie bei dir hab ich auch zu hören bekommen bekommen: “Die Investition in die innere Qualität zahlt sich langfristig aus. Features werden schneller umgesetzt, der Wartungsaufwand ist geringer, die Stabilität erhöht sich und die Kundenzufriedenheit ist dadurch auch höher.” Ich hab dann auch gesagt: “Dass der Kunde aber nicht für die innere Qualität bezahlt sondern für die abgelieferte Funktionalität.” Danach hatte das Team den Eindruck, der PO hätte nicht genug Vertrauen in das Team, denn er ist der Meinung, dass das Team nicht intensiv genug am Gesamtziel arbeiten würde.
    Da hatte ich mal wieder was angerichtet und war mit meinem Latein am Ende. Als Vertrauensbeweis hab ich dann die ToDos für die Item Done Regeln im nächsten Sprint doch eingeplant und geh der Diskussion nun aus dem Weg. Obwohl ich nach wie vor der Meinung bin, dass ein stures Festhalten an den Item Done Regeln auch nicht richtig sein kann.
    Für mich stellt sich die Frage, ob die Item Done Regeln wichtiger sind als das Commitmend? Für mich als PO ist das Commitmend höher, da sich darauf meine Planung ausrichtet. Für das Team sind es die Item Done Regeln, denn sie sind für die Qualität zuständig. Was nun?

    Auf jeden Fall ist es schön zu lesen, dass auch andere POs mit ähnlichen Problemen zu tun haben :-)

  2. Pingback: Agile Architektur « Agile Rescue

Comments are closed.