YAGNI-Prinzip

Was ist das YAGNI-Prinzip, welche Gründe gibt es für die Abweichung davon und was sind die Vorteile?

Implementiere nur Features, die wirklich benötigt werden

YAGNI ist ein Akronym und steht für „You Ain’t Gonna Need It“, also „Du wirst es nicht benötigen“. Es adressiert Entwickler, die gerne vorausdenken und zusätzliche Funktionen programmieren, in der Annahme, diese zu einem späteren Zeitpunkt zu benötigen. Das YAGNI-Prinzip ist im Kontext des Extreme Programming (XP) entstanden und fordert, diese häufig gelebte Praxis zu unterbinden und lediglich die Features zu implementieren, die konkret benötigt, besprochen oder beauftragt wurden.

Gründe für die Abweichung vom YAGNI-Prinzip

Es gibt eine Reihe von Gründen, warum Entwickler Features implementieren, die heute noch nicht benötigt werden. Eine Ursache für die Abweichung von YAGNI liegt im Requirements Engineering bzw. im Anforderungsmanagement. Je besser das Anforderungsmanagement funktioniert, desto weniger Aufwände entstehen aufgrund von Unklarkeit, Unvollständigkeit oder Interpretation. Ansonsten kann leicht folgendes passieren:

  • Entwickler interpretieren Anforderungen und implementieren mehr als konkret gefordert wird. Evtl. fehlen auch Anforderungen oder Anforderungen sind ungenau beschrieben, so dass Entwickler situativ entscheiden, welche Features noch implementiert werden müssen.
  • Um zukünftige Anforderungen möglichst einfach umsetzen zu können, werden Features möglichst generisch implementiert. Gerade in einem volatilen Umfeld mit sich häufig ändernden oder neuen Anforderungen ist dies regelmäßig zu beobachten. Flexibilität ist hier das Stichwort.

Es gibt auch eine Reihe von weiteren Gründen, die zur Abweichung vom YAGNI-Prinzip beitragen:

  • Entwickler wollen den Auftraggeber mit Funktionalität überraschen, die er nicht erwartet. Dies wird auch als Gold Plating bezeichnet.
  • Entwickler haben Zeit, die ihnen in der Zukunft vielleicht fehlen wird.
  • Entwickler haben Spaß daran, eine Architektur zu entwerfen, die für gedachte, zukünftige Anforderungen gewappnet ist.
  • Entwickler erhoffen sich Vorteile bspw. beim Testing oder beim Continuous Delivery.

Das YAGNI- und das KISS-Prinzip

Das YAGNI-Prinzip und das KISS-Prinzip ergänzen sich. Das KISS-Prinzip – Keep It Simple and Stupid – sucht nach einer möglichst einfachen Lösung zu einer Aufgabenstellung. „Kompliziert kann jeder“, aber die Kunst liegt in der Einfachheit einer Lösung. Das YAGNI-Prinzip ergänzt KISS, in dem es die Frage „brauchen wir dies wirklich“ stellt, und damit die Antwort in Richtung der Vermeidung von Aufwänden lenkt. So kann es bspw. sein, dass

  • keine Pattern implementiert,
  • keine Bibliotheken benutzt und
  • keine Deployment Prozesse automatisiert

werden.

Nichtsdestotrotz kann es natürlich Sinn ergeben, eine Frage nach „brauchen wir das wirklich“ auch mit „ja“ zu beantworten. Dies sollte idealerweise im Zuge einer gemeinsamen Abstimmung bspw. mit dem Team, dem Product Owner, dem Projektleiter, dem Produktmanager und ggf. auch mit dem Auftraggeber besprochen und vereinbart werden. Und natürlich passiert es auch regelmäßig, dass Entwicklungsteams im Laufe einer Entwicklung schlauer werden und sich sagen, „hätten wir es damals anders gemacht, würde es heute schneller und leichter funktionieren“. Die Folge können Aufwände und Kosten im Form eines Refactorings sein. Dies kann allerdings niemals eine Aufforderung sein, Features auf „Verdacht“ zu implementieren.

Faktoren beim YAGNI-Prinzip

Welche Faktoren bzw. Fragen gibt es im Zuge des YAGNI-Prinzips, die Entwickler bei der richtigen Entscheidung unterstützen? Hier eine Auswahl:

  • Ist es 100% sicher, dass die Implementierung benötigt wird?
  • Wie hoch sind die Investitionskosten?
  • Wie lange dauert die Implementierung?
  • Welche Opportunitätskosten entstehen?

Oftmals lassen sich solche Fragen nicht unmittelbar beantworten. Das liegt u. a. daran, dass Aussagen über die Zukunft grundsätzlich schwierig sind und sich nicht leicht quantifizieren lassen. Auch aus diesem Grund ergibt es Sinn, sich mit Kollegen abzustimmen und gemeinsam eine gute Entscheidung zu treffen. In agilen Entwicklungen bietet sich bspw. das Sprint Planning 2 dafür an.

Vorteile beim YAGNI-Prinzip

Werden nur diejenigen Anforderungen umgesetzt, die eindeutig implementiert werden müssen, ergeben sich einige Vorteile:

  • Ein Feature Creep wird vermieden.
  • Es entsteht keine Bloatware, also Software mit Funktionen, die kaum oder gar nicht genutzt werden.
  • Nicht implementiere Funktionen müssen nicht getestet, dokumentiert und supportet werden. Somit entsteht kein (unnötiger) Aufwand.
  • Der Ertrag steigt, denn der Aufwand für die Implementierung scheinbar benötigter Funktionen entfällt.
  • Die Codebasis bleibt „schlanker“ und ist damit leichter zu pflegen.

 

YAGNI-Prinzip - Implementiere lediglich Features, die wirklich benötigt werden

Hinweise:

Bei der Verwendung des YAGNI-Prinzips bietet sich die Kombination mit anderen Prinzipien und Techniken wie Refactoring, automatisiertes Testing und Continuous Integration zu verwenden.
Hier finden Sie einen Beitrag über den besten Prozess im Anforderungsmanagement.

Dienstleister gesucht?

Softwareentwicklung aus Berlin