You aren't gonna need it
You aren't gonna need it

Als Entwickler steht man unter enormen Druck, immer mehr Features in kürzeren Zeitabständen umsetzen zu müssen. Um diesen Anforderungen gerecht zu werden, versuchen sie, neue Wege zu finden. So wird meistens bereits bei der Erstellung neuer Features geraten, welche möglichen Änderungsanforderungen in Zukunft gefordert werden könnten und diese werden vorbereitet, zum Beispiel durch das zusätzliche Einbauen von überflüssigen Design Pattern oder sogar Hooks, die nachhaltig Lücken in der Anwendung hinterlassen.

Wenn man bedenkt, dass man 20% seiner Zeit dafür verwendet, 80% des Features umzusetzen und entsprechend die restlichen 80% der Zeit benötigt, um die restlichen 20% zu vervollständigen, sollte man sich nicht in solchen Details verlieren. Stattdessen sollte man sich auf das eigentliche Ziel fokussieren.

Werden hier noch Umwege gemacht und spekuliert, welche Features in Zukunft vielleicht anfallen könnten, verliert man wertvolle Zeit. Somit steigt das Risiko, nicht nur unleserlichen Code zu produzieren., vielmehr wird aufgrund von plötzlichem Zeitmangel auch zwangsläufig die Qualität darunter leiden. Die Folge von sinkender Qualität sind steigende Wartungs- und Unterhaltskosten. Die Mehrarbeit steht also in keinem Verhältnis zu seinem Nutzen. Nicht zu vergessen sind auch die Verzögerungskosten, da in der Zeit, in der dieses Feature künstlich komplexer gestaltetwurde, andere Features liegen lassen.

Fragt man Entwickler, wie hoch die Verzögerungskosten durch diese Mehrarbeit sind, ist die Antwort meistens gleich: Nur wenig mehr. Wenn wir allerdings statt dem Aufbau von unnötiger Komplexität lieber dem Refaktorieren von Code widmen, senken wir die Wartungskosten. Entwickeln wir neue Features, die akut benötigt werden, senken wir die Verzögerungskosten.

Überflüssigen Code produziert man meistens bei kleineren Projekten, sichtbar werden die Auswirkungen jedoch hauptsächlich bei Großprojekten.

Martin Fowler unterscheidet hier zwischen 3 Arten von Feature:

  1. Ein nicht benötigtes Feature entwickeln
    Es wird Zeit und Geld in Features investiert, die nicht gebraucht werden. Dadurch müssen die Kosten der Entwicklung sowieso die Wartungskosten getragen werden. Zusätzlich werden Verzögerungskosten erzeugt, da höher priorisierte Features vernachlässigt werden.
  2. Ein (in Zukunft) benötigtes Feature falsch entwickeln
    Wurde ein Feature entwickelt, das auch tatsächlich gebraucht wird, muss es natürlich auch richtig entwickelt werden. Wurde das Feature komplett und auch richtig umgesetzt? Sonst müssen neben den üblichen Entwicklungs- und Wartungskosten auch für die Reparatur wieder Ressourcen aufgewendet werden.
  3. Ein (in Zukunft) benötigtes Feature richtig entwickeln
    Glücklicherweise wurde ein Feature entwickelt, das der Kunde auch tatsächlich in dieser Form anfordert, allerdings haben wir immer noch die Wartungs- und Verzögerungskosten, da wir falsch priorisiert haben. Andere Features hätten einen höheren Mehrwert gehabt.

HINTERLASSE EINE ANTWORT