Wie immer interessier mich: wie siehst Du das YAGNI Prinzip? Befolgst Du es? Verletzt Du es? Welche Symptome hast Du in Deiner Praxis bei YAGNI Verletzungen erlebt? Und nicht vergessen, mit einem *Abo* verpasst Du kein Video mehr, weil zu diesem Thema gibt es definitiv mehr Videos in den nächsten Wochen.
Das ist ein fantastisches Video. Ich bin sehr froh, dass es deinen Kabel gibt :) ich habe gerade angefangen Informatik zu studieren und Yagni wird auf den meisten Seiten leider viel zu oberflächlich erklärt. Durch dich bekommt man da einen richtig guten Eindruck. Dankeschön!
Bei mir ist es schon so, dass ich als Entwickler die Anforderungen direkt mit dem Kunden kläre. Das ist aber der Tatsache geschuldet, dass ich als Einzelkämpfer unterwegs bin und mein Chef wenig Ahnung von der Entwicklung hat. Wenn er die Anforderung machen würde, würden bei mir ein Haufen Anforderungen auflaufen, die technisch nicht in gewünschten Zeitraum umsetzbar wären, weil die dafür notwendigen Voraussetzungen erst geschaffen werden müssen. Wenn mir aber bei der Umsetzung auffällt, dass offensichtlich eine Anforderung nicht ausreichend spezifiziert wurde, wird die Umsetzung erstmal gestoppt und die Anforderung mit dem Kunden so lange konkretisiert bis klar ist, was umzusetzen ist. Allerdings hatte ich erst vor kurzem dem Fall, dass der Kunde in kurzem Zeitraum die Priorität der Anforderungen geändert hat. Zwischenzeitlich hatte ich schon angefangen, diese umzusetzen. Dann kam die Info vom Kunden, dass er die Anforderung die ich gemäß seiner Anforderung umgesetzt habe nochmal intern klären muss, da diese wohl doch nicht den Vorstellungen seiner Kollegen entspricht. In dem Moment ist vor meinem geistigen Auge mein Kopf explodiert. Nach Umsetzung und Implementierung dieser priorisierenten Anforderung musste ich nun erstmal recherchieren, was als Nächstes umzusetzen wäre, da durch diese Repriorisierung meine Todo-Liste natürlich nicht mehr synchron war. Auch gab seit der Stoppsetzung vor gut 5 Monaten seitens des Kunden keine überarbeitete Anforderung, sodass ich dort gar nicht hätte weitermachen können. Ende des Lieds. Mein Chef und ich haben bei den Kunden nachgehakt und warten aktuell auf Rückmeldung. Solange arbeite ich parallel an dem Refactoring der Anwendung, da ich massive Änderungen an der Datenhaltung (DB) vorgenommen habe (u.a. wegen Performance, nicht mehr benötigten Daten ...). Wenn die irgendwann mal fertig ist, freue ich schon auf die Implementierung. Das wird sicher anstrengend werden.
Hey Oliver, Stimmt, den Aspekt hab ich gar nicht erwähnt - Mist! Hast total Recht, ist aber leider auch nicht besser und genau so gefährlich :) Gruß David
Das größte Problem in der Entwicklung ist, dass der Kunde einem nicht vertrauen kann, egal obs zu schnell oder zu langsam geht. Es muss immer genauso lange dauern, wie man vereinbart hat. Gerade wenn man YAGNI korrekt anwendet, ist man sehr effektiv unterwegs und muss oftmals fertige Arbeit absichtlich in der Schublade liegen lassen, weil der Kunde sonst denkt, man hätte ihn übers Ohr gehauen und zu viel berechnet.
@@DavidTielke Die "Ideen" mit "Das könnte der Kunde doch mal brauchen und gut finden" kommen leider von der Chef-Etage. Die müssen dann auch alle fleißig implementiert werden ohne das Sie der Kunde je bestellt hat. Denn das macht ein gutes Produkt aus! Mittlerweile ist das Projekt ein Elfenbeinturm. Hat schon von Anfang an so begonnen. Erst sollte die Authentifizierung nur über OpenLDAP gehen, dann hat man gemerkt das kaum jemand OpenLDAP im Einsatz hat und Active Directory musste dazu. Weil das Ding dann in die Cloud sollte musste App Authentifizierung (Benutzer in der Datenbank) noch dazu. Für alle Authentifizierungsmethoden dann natürlich auch noch 2FA, sowohl über App wie auch über SMS Gateway wie auch über E-Mail. Letzendlich nutzen die Kunden jetzt nur App Authentifizierung und sonst nix. Das Zeug schleifen wir natürlich weiterhin mit weil man hat es ja mal programmiert und vielleicht braucht man es nochmal. Heißt, jede Änderung am User-Objekt muss auch mit alle Authentifizierungsmethoden funktionieren und getestet werden. Und wenn Ihr jetzt denkt: Warum nicht einfach einen Identity Service wie Keycloak nutzen... Ja, warum eigentlich nicht?.... Weil es Fancy ist alles selbst zu machen. Man will sich ja nicht abhängig machen.... Nur das wir eh schon abhängig sind von OTC und Microsoft. Zum Wahnsinnig werden sowas. Hauptsache alles implementiert. Vielleicht sollte ich dazu erwähnen das wir nur 2 Entwickler waren die auch noch zusätzlich CI/CD in der OTC mit gemacht haben.... Hab mittlerweile das Unternehmen verlassen weil es mir zu bunt wurde. So ne Anekdote aus dem Alltag :D
Aber wie ist es Dingen die mir selbst in Zukunft das Entwickeln erleichtern. Z.b ein Module so zu bauen, dass es leichter erweiterbar ist. Oder das logging so zu gestalten, dass Fehler schneller zu finden sind, oder etwas umzuschreiben damit es leichter verständlicher wird (Clean code). Sowas wird der Kunde sicherlich nicht beauftragen. Wenn ich mich streng nur danach richte was der Kunde will, dann habe ich doch irgendwann eine sehr unflexible, unsaubere Software?
Hallo Paul, mit diesen Dingen die Du schilderst bist Du genau bei den nicht-funktionalen Anforderungen - selbstverständlich musst Du das dann einbauen, WENN es dazu eine NFA gibt! YAGNI sagt das Du nichts machen sollst, zu dem es keine Anforderung gibt - wenn ihr Eure Software aber einfach erweiterbarer entwerfen wollt (das ist eine NFA) dann musst Du das natürlich auch berücksichtigen! Gruß David
Vorsicht mit "leichter erweiterbar" - Häufig ist bedeutet das: Leichter erweiterbar in die Richtung, in der man neue Anforderungen vermutet. Wenn man aber eine Architektur komplexer macht, um bestimmte Erweiterungen leichter zu machen, macht man damit oft andere schwieriger, eben wegen der zusätzlichen Komplexität. Wenn dann die Anforderungen ganz anderer Art sind als man ursprünglich angenommen hat, steht man mit einer unnötig komplexen Architektur da. Faustregel: Wenn zusätzlicher Code geschrieben wird, um mögliche zukünftigen Erweiterungen zu erleichtern, ist das fast immer eine Verletzung von YAGNI.
Super Video! Für mich wäre auch schon dann YAGNI gegeben, falls ein einfaches Feature so eingebaut wird, daß es darüberhinaus unangefordert aber konfigurierbar ist, damit meine ich noch nicht unbedingt Feature-Toggle, sondern zusätzliche konfigurierbare Featureoptionen - z.B.: Farbkonfigurationen; wenn diese als konfigurierbare Features vom Kunden angefordert sind ist das niemals YAGNI. Üblicherweise findet man deaktivierbare Features in Standardsoftware, deren Vielzahl konfigurierbarer Einstellungen ein Hinweis auf YAGNI-Verletzungen sein kann mit den von Dir geschilderten schleichenden Qualitätsproblemen die meiner Meinung nach eher bei (zu) kleinen oder unterbesetzten Teams mit nicht/zu wenig automatisierten Abläufen arbeiten. Allerdings was wäre die Welt ohne konfigurierbare Standardsoftware? Schließlich benutzen wir alle gerne gewisse verbreitete Standard-Software (Betriebssysteme, Browser, Email, Office, Entwickler benutzen die gleiche VCS, Standard-IDE, Datenbanksysteme usw.)
Hallo Bernd, guter Punkt mit der Konfigurierbarkeit, das hatte ich gar nicht mehr auf dem Plan. Aber ja: meist nicht YAGNI-Konform. Zu konfigurierbarer Software gibts in der nächsten Woche voraussichtlich ein Video :) Gruß David
@@DavidTielke Das kenne ich sehr genau, auf der einen Seite ist es die kreative Freiheit der Entwicklers, auf der anderen Seite kommen die Probleme hinzu.
Und wenn der Product Owner sagt, die Funktionalen Anforderungen hätte die Entwicklung doch sehen müssen. Das ist ja zu wenig was "wir" gemacht haben? Wo fange ich an und wo höre ich auf, in der Entwicklung?
Dann würde ich sagen, das es eine verdammt dünne Ausrede für das eigene Versagen ist... YAGNI erzeugt ja massiv viele Probleme wenn das so betrieben wird. Dann sollte man lieber an den Anforderungen arbeiten. Gruß David
Ich kenne die Anwendung des Prinzips aus eigener Erfahrung auch, und zwar insbesondere bei nichtfunktionalen Anforderungen. Da wird dann gerne mal sowas gesagt wie „Transaktionen? Brauchen wir hier nicht, das hat der Kunde nicht bestellt.“ Wenn dann am Ende im Betrieb die Daten inkonsistent sind, möchte ich bei dem Gespräch aber nicht dabei sein, wenn man versucht, die Verantwortung abzuwälzen.
Junge Entwickler kommen öfter mit Verbesserungsvorschlägen, bei denen eine neue Technologie im Spiel ist. Beispiel: "Chef, wir brauchen Feature-Flags". Leider für den Chef schwer zu durchschauen, ob die Technologie wirklich gebraucht wird oder der Entwickler nur gerade Lust auf was neues hat. Oder womöglich auf der nächsten Party prahlen will, wie modern sein Team ist. (ok war sehr gemein)
Wobei es sich im Falle des Feature Flags relativ schnell feststellen lässt. In unserem Team hatten wir in der Vergangenheit öfter das Problem, dass Features released worden sind, die noch gar nicht raus sollten. Um das zu lösen, haben wir Feature Flags benötigt und eingeführt. Bei der Diskussion, warum wir eine neue Technologie benötigen, hilft es klar zu stellen, wo sie einen Nutzen bringt bzw. vorher zu schauen ob etwas am Prozess verbessert werden muss, um das Problem zu lösen.
![Das DRY Principle - Don't repeat yourself [Mit Beispiel und Profi-Tipp]](http://i.ytimg.com/vi/JSx96SnDVKg/mqdefault.jpg)
![Das DRY Principle - Don't repeat yourself [Mit Beispiel und Profi-Tipp]](/img/tr.png)
Wie immer interessier mich: wie siehst Du das YAGNI Prinzip? Befolgst Du es? Verletzt Du es? Welche Symptome hast Du in Deiner Praxis bei YAGNI Verletzungen erlebt? Und nicht vergessen, mit einem *Abo* verpasst Du kein Video mehr, weil zu diesem Thema gibt es definitiv mehr Videos in den nächsten Wochen.
Das ist ein fantastisches Video. Ich bin sehr froh, dass es deinen Kabel gibt :) ich habe gerade angefangen Informatik zu studieren und Yagni wird auf den meisten Seiten leider viel zu oberflächlich erklärt. Durch dich bekommt man da einen richtig guten Eindruck. Dankeschön!
Danke für deine Videos. Tolle Inhalte, auf dem Punkt gebracht.
Hey Stephan,
schön das es Dir gefällt, das freut mich sehr!
Gruß David
Bei mir ist es schon so, dass ich als Entwickler die Anforderungen direkt mit dem Kunden kläre. Das ist aber der Tatsache geschuldet, dass ich als Einzelkämpfer unterwegs bin und mein Chef wenig Ahnung von der Entwicklung hat. Wenn er die Anforderung machen würde, würden bei mir ein Haufen Anforderungen auflaufen, die technisch nicht in gewünschten Zeitraum umsetzbar wären, weil die dafür notwendigen Voraussetzungen erst geschaffen werden müssen.
Wenn mir aber bei der Umsetzung auffällt, dass offensichtlich eine Anforderung nicht ausreichend spezifiziert wurde, wird die Umsetzung erstmal gestoppt und die Anforderung mit dem Kunden so lange konkretisiert bis klar ist, was umzusetzen ist.
Allerdings hatte ich erst vor kurzem dem Fall, dass der Kunde in kurzem Zeitraum die Priorität der Anforderungen geändert hat. Zwischenzeitlich hatte ich schon angefangen, diese umzusetzen.
Dann kam die Info vom Kunden, dass er die Anforderung die ich gemäß seiner Anforderung umgesetzt habe nochmal intern klären muss, da diese wohl doch nicht den Vorstellungen seiner Kollegen entspricht. In dem Moment ist vor meinem geistigen Auge mein Kopf explodiert.
Nach Umsetzung und Implementierung dieser priorisierenten Anforderung musste ich nun erstmal recherchieren, was als Nächstes umzusetzen wäre, da durch diese Repriorisierung meine Todo-Liste natürlich nicht mehr synchron war.
Auch gab seit der Stoppsetzung vor gut 5 Monaten seitens des Kunden keine überarbeitete Anforderung, sodass ich dort gar nicht hätte weitermachen können.
Ende des Lieds. Mein Chef und ich haben bei den Kunden nachgehakt und warten aktuell auf Rückmeldung. Solange arbeite ich parallel an dem Refactoring der Anwendung, da ich massive Änderungen an der Datenhaltung (DB) vorgenommen habe
(u.a. wegen Performance, nicht mehr benötigten Daten ...). Wenn die irgendwann mal fertig ist, freue ich schon auf die Implementierung.
Das wird sicher anstrengend werden.
Manchmal will der Entwickler dem Chef imponieren, wie toll er mitdenkt und wie schnell er ist. Garniert mit dem Spruch "das hab ich mal eben gemacht"
Hey Oliver,
Stimmt, den Aspekt hab ich gar nicht erwähnt - Mist! Hast total Recht, ist aber leider auch nicht besser und genau so gefährlich :)
Gruß David
Das größte Problem in der Entwicklung ist, dass der Kunde einem nicht vertrauen kann, egal obs zu schnell oder zu langsam geht. Es muss immer genauso lange dauern, wie man vereinbart hat.
Gerade wenn man YAGNI korrekt anwendet, ist man sehr effektiv unterwegs und muss oftmals fertige Arbeit absichtlich in der Schublade liegen lassen, weil der Kunde sonst denkt, man hätte ihn übers Ohr gehauen und zu viel berechnet.
Gutes Video. Hör grad zum ersten mal von YAGNI und kann einige Probleme bestätigen.
Hallo Marco, freut mich, das dir das Video gefällt... Und welches der YAGNI Prinzip Probleme habt ihr?
Gruß David
@@DavidTielke Die "Ideen" mit "Das könnte der Kunde doch mal brauchen und gut finden" kommen leider von der Chef-Etage. Die müssen dann auch alle fleißig implementiert werden ohne das Sie der Kunde je bestellt hat. Denn das macht ein gutes Produkt aus! Mittlerweile ist das Projekt ein Elfenbeinturm. Hat schon von Anfang an so begonnen. Erst sollte die Authentifizierung nur über OpenLDAP gehen, dann hat man gemerkt das kaum jemand OpenLDAP im Einsatz hat und Active Directory musste dazu. Weil das Ding dann in die Cloud sollte musste App Authentifizierung (Benutzer in der Datenbank) noch dazu. Für alle Authentifizierungsmethoden dann natürlich auch noch 2FA, sowohl über App wie auch über SMS Gateway wie auch über E-Mail. Letzendlich nutzen die Kunden jetzt nur App Authentifizierung und sonst nix. Das Zeug schleifen wir natürlich weiterhin mit weil man hat es ja mal programmiert und vielleicht braucht man es nochmal. Heißt, jede Änderung am User-Objekt muss auch mit alle Authentifizierungsmethoden funktionieren und getestet werden. Und wenn Ihr jetzt denkt: Warum nicht einfach einen Identity Service wie Keycloak nutzen... Ja, warum eigentlich nicht?.... Weil es Fancy ist alles selbst zu machen. Man will sich ja nicht abhängig machen.... Nur das wir eh schon abhängig sind von OTC und Microsoft. Zum Wahnsinnig werden sowas. Hauptsache alles implementiert. Vielleicht sollte ich dazu erwähnen das wir nur 2 Entwickler waren die auch noch zusätzlich CI/CD in der OTC mit gemacht haben.... Hab mittlerweile das Unternehmen verlassen weil es mir zu bunt wurde. So ne Anekdote aus dem Alltag :D
Gutes Video!
Aber wie ist es Dingen die mir selbst in Zukunft das Entwickeln erleichtern. Z.b ein Module so zu bauen, dass es leichter erweiterbar ist. Oder das logging so zu gestalten, dass Fehler schneller zu finden sind, oder etwas umzuschreiben damit es leichter verständlicher wird (Clean code). Sowas wird der Kunde sicherlich nicht beauftragen. Wenn ich mich streng nur danach richte was der Kunde will, dann habe ich doch irgendwann eine sehr unflexible, unsaubere Software?
Hallo Paul,
mit diesen Dingen die Du schilderst bist Du genau bei den nicht-funktionalen Anforderungen - selbstverständlich musst Du das dann einbauen, WENN es dazu eine NFA gibt! YAGNI sagt das Du nichts machen sollst, zu dem es keine Anforderung gibt - wenn ihr Eure Software aber einfach erweiterbarer entwerfen wollt (das ist eine NFA) dann musst Du das natürlich auch berücksichtigen!
Gruß David
Vorsicht mit "leichter erweiterbar" - Häufig ist bedeutet das: Leichter erweiterbar in die Richtung, in der man neue Anforderungen vermutet. Wenn man aber eine Architektur komplexer macht, um bestimmte Erweiterungen leichter zu machen, macht man damit oft andere schwieriger, eben wegen der zusätzlichen Komplexität. Wenn dann die Anforderungen ganz anderer Art sind als man ursprünglich angenommen hat, steht man mit einer unnötig komplexen Architektur da. Faustregel: Wenn zusätzlicher Code geschrieben wird, um mögliche zukünftigen Erweiterungen zu erleichtern, ist das fast immer eine Verletzung von YAGNI.
Super Video!
Für mich wäre auch schon dann YAGNI gegeben, falls ein einfaches Feature so eingebaut wird, daß es darüberhinaus unangefordert aber konfigurierbar ist, damit meine ich noch nicht unbedingt Feature-Toggle, sondern zusätzliche konfigurierbare Featureoptionen - z.B.: Farbkonfigurationen; wenn diese als konfigurierbare Features vom Kunden angefordert sind ist das niemals YAGNI.
Üblicherweise findet man deaktivierbare Features in Standardsoftware, deren Vielzahl konfigurierbarer Einstellungen ein Hinweis auf YAGNI-Verletzungen sein kann mit den von Dir geschilderten schleichenden Qualitätsproblemen die meiner Meinung nach eher bei (zu) kleinen oder unterbesetzten Teams mit nicht/zu wenig automatisierten Abläufen arbeiten.
Allerdings was wäre die Welt ohne konfigurierbare Standardsoftware? Schließlich benutzen wir alle gerne gewisse verbreitete Standard-Software (Betriebssysteme, Browser, Email, Office, Entwickler benutzen die gleiche VCS, Standard-IDE, Datenbanksysteme usw.)
Hallo Bernd,
guter Punkt mit der Konfigurierbarkeit, das hatte ich gar nicht mehr auf dem Plan. Aber ja: meist nicht YAGNI-Konform. Zu konfigurierbarer Software gibts in der nächsten Woche voraussichtlich ein Video :)
Gruß David
herzlichen Dank!
Sehr gerne :)
@@DavidTielke Das kenne ich sehr genau, auf der einen Seite ist es die kreative Freiheit der Entwicklers, auf der anderen Seite kommen die Probleme hinzu.
Das stimmt, aber die Balance ist wichtig :) Die Frage ist halt immer, woran es liegt. Oft ist es das Anforderungsmanagement.
Und wenn der Product Owner sagt, die Funktionalen Anforderungen hätte die Entwicklung doch sehen müssen.
Das ist ja zu wenig was "wir" gemacht haben?
Wo fange ich an und wo höre ich auf, in der Entwicklung?
Dann würde ich sagen, das es eine verdammt dünne Ausrede für das eigene Versagen ist... YAGNI erzeugt ja massiv viele Probleme wenn das so betrieben wird. Dann sollte man lieber an den Anforderungen arbeiten.
Gruß David
Aha, der PO will also, dass die Entwickler hellsehen. Hört sich nach schlechter Kommunikation an.
Da bin ich dabei :D
@Hiemies Hey: Gib Mal Beispiele.
Gruß David
Ich kenne die Anwendung des Prinzips aus eigener Erfahrung auch, und zwar insbesondere bei nichtfunktionalen Anforderungen. Da wird dann gerne mal sowas gesagt wie „Transaktionen? Brauchen wir hier nicht, das hat der Kunde nicht bestellt.“ Wenn dann am Ende im Betrieb die Daten inkonsistent sind, möchte ich bei dem Gespräch aber nicht dabei sein, wenn man versucht, die Verantwortung abzuwälzen.
Entscheidend ist der Hinweis „YAGNI ist nicht töten sondern diskutieren“
Junge Entwickler kommen öfter mit Verbesserungsvorschlägen, bei denen eine neue Technologie im Spiel ist. Beispiel: "Chef, wir brauchen Feature-Flags". Leider für den Chef schwer zu durchschauen, ob die Technologie wirklich gebraucht wird oder der Entwickler nur gerade Lust auf was neues hat. Oder womöglich auf der nächsten Party prahlen will, wie modern sein Team ist. (ok war sehr gemein)
Wobei es sich im Falle des Feature Flags relativ schnell feststellen lässt. In unserem Team hatten wir in der Vergangenheit öfter das Problem, dass Features released worden sind, die noch gar nicht raus sollten. Um das zu lösen, haben wir Feature Flags benötigt und eingeführt.
Bei der Diskussion, warum wir eine neue Technologie benötigen, hilft es klar zu stellen, wo sie einen Nutzen bringt bzw. vorher zu schauen ob etwas am Prozess verbessert werden muss, um das Problem zu lösen.
KVP 😂😂😂😂
EDV-Jargon == LOL.