Neben EinmalUndNurEinmal eines der wichtigsten Prinzipien für EinfachesDesign in ExtremeProgramming.

"Mach nur das, was wirklich notwendig ist!"

• kein Schnickschnack
• keine Vorsorge für eventuelle zukünftige Erweiterungen
• keinen Ballast, der vielleicht gar nicht gebraucht wird
• keine Funktionalitäten, die nicht ganz oben auf der Prioritätenliste stehen

RonJeffries wird im Allgemeinen als der "Erfinder" von Yagni akzeptiert. Er schreibt in news:comp.software.extremeprogramming:

"YAGNI means "You Aren't Gonna Need It". It is not an XP practice, but it is a mantra that some of us use. I am probably the perpetrator of "YAGNI".

YAGNI means that when we are programming, and we think of a cool feature or extension that "we're gonna need", we say to ourselves, "you aren't gonna need it", and we leave the feature out. The reason that we do this is that our customer decides what features to build, the programmers do not.

YAGNI doesn't prohibit thinking: it prohibits programming unrequested features. YAGNI doesn't prohibit working on any general kind of thing: it prohibits programming on things that do not have high priority with the customer.

Folks have extended YAGNI thinking to other realms. It's probably always wise to use YAGNI to push back against things we always do. Do we always write a big requirements document? Maybe we aren't going to need it. (WAGNI? Hmm) Do we always write a test plan? WAGNI. Do we always make a risk list? WAGNI?

Well, maybe we do need it. Some of the risks are techical in nature, some are customer. Certainly the team ought to talk about risks, and we put them together so that they will talk. We don't have a list of things they must, should, may, or may not talk about. We trust that they'll talk about the things that their various expertise makes important to them. Risk might be one of those things."

Daß nichts dauerhaft Unnötiges programmiert werden sollte, ist nicht besonders neu oder erhellend.

Neu bei YAGNI ist aber die Aussage, daß darüber hinaus auch nichts programmiert werden sollte, das man (erst) in Zukunft brauchen wird. Weil man es später besser machen kann; weil man es dann zwar braucht, aber anders; weil man später weniger Vermutungen über Anforderungen und Code-Umfeld anstellen muß; weil es einen bis dahin nur beim Refactoring bremsen würde; weil man so schneller mehr Code für das jeweilige "Jetzt" fertig hat, statt für's "Später"; oder weil sich eben herausstellt, daß man es doch nicht gebraucht hat.

Deshalb sollte man sich immer so verhalten, als ob man solchen "Zukunfts-Code" tatsächlich nie benötigen wird, dann fährt man besser.

Die allgemeine Idee ist, dass man - um effizient zu sein - immer nur Dinge tun, planen, und vor allem programmieren soll, wenn sie und weil sie tatsächlich jetzt erforderlich sind. Niemals sollte man etwas programmieren, nur weil man davon ausgeht, dass das Feature in Zukunft benötig wird. Die Wahrscheinlichkeit ist zu hoch, dass man sich irrt und der Bedarf nie eintritt.

Vorsicht - mir ist das deutlich zu allgemein ausgedrückt. Auch und gerade ExtremeProgramming trägt dem Umstand Rechnung, das man bestimmte Dinge auf jeden Fall brauchen wird, z. B. EinfachesDesign - daher die Wichtigkeit von CodeRefactoring. Ich denke sogar, dass sich YAGNI (im Kontext von ExtremeProgramming) ausschließlich auf das Implementieren von Funktionalität bezieht. -- IljaPreuß

Dinge, auf die sich WerdenWirNichtBrauchen sinnvoll anwenden lässt:

• Funktionalität
• Dokumentation
• ...

• EinfachesDesign
• Tests
• ...

Voraussetzungen für die Anwendung von WerdenWirNichtBrauchen auf Funktionalität:

• EinfachesDesign lässt mich leicht neu benötigte Funktionalität hinzufügen
• KomponentenTests und AkzeptanzTests stellen dabei sicher, dass ich nichts kaputt mache
• mit Hilfe von CodeRefactoring sorge ich anschließend dafür, dass ich wieder ein EinfachesDesign bekomme

Kommt dabei wirklich etwas Vernünftiges heraus? Das liest sich wie eine Regel für die Ex-und-Weg-Programmierung. -- RalfEbert

Sieh es mal nicht nur unter dem Aspekt der Programmierung. Es ist doch gut, sich immer auf die wirklich wichtigen Dinge zu konzentrieren, Prioritäten zu setzen und diese auch einzuhalten.

Wenn jemand z. B. Dinge realisiert, deren Vorteile erst in einem Jahr wirksam werden, dann haben sich bis dahin vielleicht die Rahmenbedingungen verschoben oder das Projekt wurde sogar abgebrochen. Entwicklungsaufgaben, die unmittelbar - innerhalb der nächsten 3 Wochen - die Qualität eines Produktes nachweislich verbessern, haben einfach Vorang.

Wenn es aber um etwas wirklich Essentielles geht (d. h. entsprechender Aufwand), dann muss das auch als eigenständige Entwicklungsaufgabe gesehen werden. Ein KundeVorOrt muss darüber informiert sein, die Sache verstehen und der Aufgabe im Rahmen des PlanungsSpiels die entsprechende Priorität geben. -- HelmutLeitner

Komisch. Ich mach immer das Gegenteil. Zuerst wird das komplexest mögliche Szenario geplant und designt, und dann werden davon Abstriche gemacht. Oder ich gebe auf. (Ganz Oder Gar Nicht) Ein halbes Produkt (bzw. so wie sich das der User vorstellt) führt nur zu Ärger. Grundsätzliche Probleme werden schon von vornherein abgecheckt und nicht unnötige Zeit in falsche Hoffnungen investiert. In C oder C++ könnte ich mir das natürlich nicht leisten, weil Pläne (Interfaces, Objekte) dort schlecht erweitert werden können. WerdenWirNichtBrauchen funktioniert nicht. --ReiniUrban

Das ist wirklich interessant: Du vertrittst hier sozusagen die "Anti-These" zum XP-Prinzip YAGNI: "Zuerst wird das komplexest mögliche Szenario geplant und designt, und dann werden davon Abstriche gemacht." Ja, YAGNI hat genau den "umgekehrten" Ansatz. Man beginnt mit dem "minimal Nötigen" (vgl. auch EinfachesDesign) und erweitert "bei Bedarf" (entsprechend des Kundenwunsches).

Ich dachte die Grundidee bei XP sei, ein Produkt zu erzeugen, das so ist, wie es sich der Abnehmer vorstellt. Hinter der Aussage, das es besser ist, ein Produkt zu liefern, das so ist, wie es sich der Entwickler vorstellt, steckt doch die Unterstellung, dass der Entwickler besser als der Abnehmer weiss, was der Abnehmer braucht.

Ich denke auch so. Eine Grundidee von XP ist ganz sicher ein Produkt zu erzeugen, das kompromisslos den Kundennutzen realisiert und sonst nichts. -- HelmutLeitner

Jau, stimmt. Nehme den Aufwand, der nach Deinen Erfahrungen in die Implementation unnötiger Details gesteckt wird. Die Hälfte dieser Zeit investierts Du um den Kunden auszuquetschen, was er denn wirklich braucht. Bringe ihn weg von Beschreibungen, *wie* er etwas realisiert haben moechte und dahin, *was* er von Dir realisiert haben moechte. Stelle Fragen zu Buzzwords, die in der Anforderung auftauchen. Hinterfrage sie, versuche herauszubekommen, was er denn wirklich meint und will. Programmiere das, was Du wirklich brauchst, sauber und fehlerfrei, und dokumentiere diese Schnittstellen ausreichend. Lasse dafuer Schnittstellen weg, die man momentan nicht benoetigt. Dann hast Du nach meiner Meinung nur das realisiert, was man braucht und ziehst Gewinn aus dieser Strategie. --BerndGiegerich

Refaktoring und Erweiterungen sind durch Modul- und Regressionstests möglich und sicher. Woher stammt die Meinung, dass Interfaces und Objekte in Sprachen mit im wesentlichen statischem Typsystem schlechter erweiterbar sind als in typlosen Sprachen oder Sprachen mit dynamischem Typsystem? Trotzdem geht es bei WerdenWirNichtBrauchen ja wohl nicht darum, ein System gegen spätere Änderungen abzusichern, sondern darum, keinen Aufwand in noch nicht vorhandene Anforderungen zu stecken. Wenn Erweiterbarkeit eine Anforderung ist, dann fällt Aufwand, der für die Erweiterbarkeit getrieben werden muss, nicht unter WerdenWirNichtBrauchen -- KurtWatzka

...Interfaces und Objekte...schlecht erweiterbar...

Es würde mich interessieren, wie du das begründest. Es widerspricht meinen Erfahrungen und es würde auch die ObjektOrientierteProgrammierung als Ganzes in Frage stellen, wenn dies so wäre. -- HelmutLeitner

Das tu ich sowieso :) Ich mach 'ne eigene Seite zu meiner XP und OO Kritik. Aber nicht heute. --ru

WardsWiki:YouArentGonnaNeedIt