Was ist YAGNI?

Man könnte doch noch …

YAGNI kurz und knapp erklärt

YAGNI steht im Englischen für „You aren’t gonna need it“. Frei übersetzt heißt das so viel wie „Du wirst es nicht brauchen“. Aber wer in der Softwareentwicklung braucht hier eigentlich was nicht?  

Bei diesem – zugegeben – etwas aus dem Zusammenhang gerissen wirkenden Satzes handelt es sich um ein Prinzip in Form eines markanten Merkspruchs. In der Softwareentwicklung arbeitet man gerne nach solchen Handlungsleitfäden, da viele Entscheidungen in einer konkreten Situation nicht durch quantitative Beweise gestützt werden können.  

Das YAGNI-Prinzip besagt in unserem Fall, dass in der Softwareentwicklung nur Dinge, z.B. Funktionen, Komponenten, etc., umzusetzen sind, die auch gebraucht werden. Darunter versteht man alles, was der Kunde explizit wünscht, beauftragt, mit seinem IT-Dienstleister konzipiert und demzufolge bezahlt. Alles andere kann man getrost ignorieren.  

Die Versuchungen der Softwareentwicklung  

YAGNI! Klingt doch eigentlich logisch, oder? Doch die Versuchungen, etwas zu entwickeln, was gar nicht erforderlich ist, sind groß, wie folgende Beispiele zeigen: 

• Auf Kundenseite wird seitens eines Mitarbeiters ein Wunsch geäußert, der nicht im Scope ist. Pflichtbewusst, wie Softwareentwickler so sind, wird sich aber Hals über Kopf ans Werk gemacht.
• Der Programmierer sieht ein cooles Feature, das er beispielsweise in der Dokumentation einer Klassenbibliothek gesehen hat und denkt sich „Hm. Das könnte mein Kunde doch auch gebrauchen.“
• Man glaubt, Analogien zu anderen Softwareentwicklungs-Projekten zu sehen und bildet sich daraufhin seine eigene Meinung darüber, was nicht alles Schönes noch gebraucht werden könnte. Und der Chef hat doch außerdem gesagt, seine Softwareentwickler sollen mehr mitdenken. 

Die Verlockungen lauern also in allen Ecken. Das Tückische darin ist, dass eine Verletzung des YAGNI-Prinzips nicht immer auffällt oder sogar noch gelobt wird. Die Auswirkungen sind dann umso gravierender.   

YAGNI ignoriert? Was soll schon passieren?  

Stellen Sie sich einfach folgende Situation in einem Industriebetrieb vor. Eine Kunde wünscht sich für die Verwaltung von Kontaktdaten in seiner Anwendung ein Datagrid – das sind tabellenartige Steuerelemente, mit denen man ähnlich wie in einem Excelsheet Daten bearbeiten kann. Außer der reinen tabellarischen Darstellung wird noch eine Sortierung für die Namensspalte gewünscht. Nun denkt sich der Entwickler aber „Es wäre doch toll, wenn man jede beliebige Spalte sortieren kann“.  

Also baut er es ein und präsentiert es seinem Kunden. Der ist natürlich hellauf begeistert. Wo ist also das Problem? Wir haben ja noch nicht erzählt, wie es weitergeht. Ab jetzt nimmt nämlich der Ärger seinen Lauf, denn Ihr Kunde steht ab jetzt quasi unter Software-Feature-Drogen. Beim nächsten Mal wird er nämlich ähnliches erwarten und die Softwareentwickler sind geneigt dem nachzugeben. Schließlich haben Sie beim ersten Mal sehr viel Wertschätzung dafür bekommen.  

Damit wird ein Stein in Ihrem Softwareentwicklungs-Projekt ins Rollen gebracht, der folgendes bewirkt: 

• Die Anforderungen werden zunehmend schwammiger, da sich alle denken „Die Entwickler finden schon irgendeine Lösung für mein Problem“.
• Die Entwickler ihrerseits programmieren immer mehr ins Blaue hinein.
• Das Risiko, viel Energie für die Konzeption, Programmierung und Testung zahlreicher unsinniger Funktionen zu verschwenden, erhöht sich.
  
• Der Fokus auf die Implementierung weniger, aber wichtiger Features mit hoher Qualität geht schleichend verloren.
• Es kommen immer mehr Funktionen hinzu, deren Nutzen eher fraglich ist, die aber trotzdem gewartet werden müssen – selbst der Button, der aussieht wie ein rosa Einhorn.
• Die Komplexität der zu entwickelnden Anwendung erhöht sich.
• Aufgrund der vielen, oftmals zusammenhängenden Funktionen, wird es immer schwieriger für die Softwareentwickler, die Anwendung zu erweitern.
• Es kommt zu Überschreitungen von Budget und Zeit. Und das kann nun wirklich niemanden freuen.

Aus dem Leuchtturm-Projekt der Softwareentwicklung ist plötzlich eine Kostenfalle geworden. Aufgrund der vielen sinnlosen Funktionen wird es zudem immer mehr Stimmen geben, die sagen „Wozu ist das Ding überhaupt gut?“. Denn ein klarer Aufgaben-Kern der Software-Lösung ist oftmals nicht mehr zu erkennen. Und das Schlimmste an dieser Situation? Die Karre steckt im Dreck und ist wahrscheinlich nur noch durch monatelanges Refactoring oder eine Neuimplementierung aus dem Schlamm zu ziehen.  

Es gilt also, die Verletzung des YAGNI-Prinzips unbedingt zu vermeiden und vorzubeugen.  

Programmieren, was programmiert werden muss  

Um die Verletzung des YAGNI-Prinzips zu vermeiden, müssen Softwareentwickler und Kunde an einem Strang ziehen. Dem Entwickler muss klar sein, dass er nur das programmiert, was der Kunde auch explizit verlangt hat. Dem Kunden muss bewusst sein, dass Anforderungen detailliert zu formulieren sind. Um nun nicht in die Gefahr eines Henne-Ei-Problems zu laufen, wo jeder nun auf die Aktion des anderen lauert, gibt es verschiedene Möglichkeiten: 

• Ist-Analyse von Arbeitsvorgängen zur Verbesserung des Prozess-Verständnisses. Sie werden überrascht sein, welche Erkenntnisse man teilweise über den eigenen Betrieb gewinnt.
• Interviews mit den potentiellen Anwendern zu Ihren Anforderungen an die neue Software-Lösung. Hier sollten auch die Entwickler zu Wort kommen und über die Umsetzungsmöglichkeiten aufklären.
• Ein Mock-Up für die visuelle Veranschaulichung zukünftiger Funktionen
• Sogenannte Spike-Implementierungen. Anhand einer kompakten Mini-Anwendung werden Anwendungsfälle einfach mal real

Kurz gesagt. Bevor man kräftig in die Tasten haut, um eine Funktion zu implementieren: Lieber noch mal drüber reden.