Weißt du, ich wusste aber an so ein Spiel denken, wenn du gewonnen hast wie Yatzi weißt du so yatzi? Das ist geil. Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Halli Hallo und herzlich Willkommen. Eine neue Folge vom Coaling Buddies Podcast steht in den Startlöchern und damit geht es auch jetzt los und ich begrüße natürlich den Tino. Tino, wie geht's dir? Moin Moin Fabi, Was geht? Mir geht's los. Was geht.
Ich hab Bock, ich hab richtig Bock, sogar muss ich sagen, ich weiß nicht, guck so aus dem Fenster, die Welt sagt gar keinen Bock, weil es ist super grau und dunkel und nass, aber ich hab richtig Bock auf ne Podcast folge. Ja, grau nass ist ja halt ne klassische Oktoberzeit. Also es ist ja auch krass, wie schnell die Zeit schon wieder
rumgeht. Ne, ich mein Oktoberfest ist ja jetzt auch schon wieder vorbei, hab ich gehört, ich denk mir immer so, Oktoberfest ist ja eigentlich gern im Oktober, war eigentlich immer n bisschen früher ne ja. Wie wie findest du das eigentlich? Wie bist du so n Oktoberfesttyp? Eigentlich. Boah, ich muss sagen ich hab ne Lederhose. OK, krass krass für. Diesen für diesen Anlass. Weil ich ab. Und an ich war früher in der Uni öfter mal so auf Studentenwiesen.
Studenten, OK. Das war geil, das hat irgendwie Bock gemacht. Obwohl warte mal, ich muss noch mal kurz überlegen, nee, ich hab schon fertig studiert und war dann glaub ich auf Studentenwiesen. Du hattest eigentlich gar keinen Zutritt mehr, aber irgendwie hast du dich reingemogelt. Ja, ich glaube, so war es.
Nee, aber irgendwie, das ist schon ganz lustig, aber weiß nicht, eigentlich würde ich mich jetzt eher nicht so sehen, dass ich da so Mega Fan bin, aber ich war zum Beispiel noch nie auf dem Oktoberfest. Wie sieht es da also auf dem richtigen Oktoberfest? Wie sieht es? Bei dir aus war ich auch nicht das Thema hatte ich auch tatsächlich letztens erst mit Freuden. Nee, hat mich auch noch nicht da.
Hingetrieben sozusagen. Also ich glaube, es ist n Erlebnis, ob es mein persönliches Highlight werden würde, kann ich nicht sagen, ich weiß nicht ob ich da so der Typ für bin, also ich hab auch keine Lederhose, bin ich ehrlich du ja ich weiß du trägst die auch privat immer ganzjährig. Nein. Nein, aber ja, wahrscheinlich.
Also würde ich zum Oktoberfest fahren, würde ich mir auch eine holen, auf jeden Fall. Also dann musst du es durchziehen, ansonsten bin ich immer mit so einem alternativ Look der halbwegs in die gleiche Richtung geht immer ganz gut davon gekommen oder? Oder wurde akzeptiert sag ich mal holzfällerstyle. Oder was und Na. Ja, also schon so mit Helmd und allem, aber na ja, keine. Lederhose, jeansbraun angemalt oder wie? Ganz genau so sah es aus, aber ich weiß nicht.
Also ich könnte sein, dass es mir zu viel Trubel ist, das richtige Oktoberfest. Ja ich, weil ich will es nicht verurteilen oder irgendwie n vor sag ich mal irgendwie voreingenommen sein, weil es finden ja schon ziemlich viele ziemlich cool und ich glaube es hat halt auch einfach n gewissen Charme. Ja, also mich würde zum Beispiel auch mal interessieren, so an alle Hörerinnen und Hörer, also wenn euch irgendwie da was, also wenn ihr sagt hier ne,
Oktoberfest ist cool, lasst uns mal wissen, wir waren beide noch nicht da oder wenn ihr sagt Wir waren auch schon da, es ist aber. Blöd auf keinen Fall hin. Also ich denke halt immer so okay. Also am Ende trinkst du da Bier mit Leuten, bloß dass du halt wahrscheinlich mit den gleichen Leuten hingehen würdest. Aber einfach normalerweise Bier günstiger trinken könntest. Kannst halt einfach ganz pragmatisch. Na ich glaub ich glaub die Stimmung ist da schon krass.
Also wenn du zur richtigen Zeit da bist, ist das bestimmt ganz. Cool? Ja glaub ich schon. Lassen wir uns. Das ist jetzt auch das Thema unserer heutigen Folge. Merke ich gerade heute geht es ums Oktoberfest. Nein, wir. Die heutige Folge ist ja ungefähr so, dass wir richtig dagegen verstoßen haben, weil wir quasi über etwas gesprochen haben, was wir eigentlich gar nicht brauchen. Genau, wo es gar nicht gehen sollte.
Heute aber pass auf, bevor wir jetzt richtig reinsteigen und du gleich mal das Thema ankündigst, wollte ich noch einmal ganz kurz einen Riesen dank loswerden und zwar an den Malte, weil Malte vielen Dank für deine Spende an uns für unseren Podcast. Das hat mir super gefreut mega Sache vielen vielen dank Liebe geht raus und in dem Sinne würde ich sagen Tino Stell mal das Thema der heutigen Folge vor. Ja, und zwar haben wir wieder eine Code Prinzip oder Softwareentwicklungsprinzipfolge.
Wir haben ja auch ne Umfrage gemacht, dass die Themen ganz gut ankommen und deswegen dachten wir uns, starten wir direkt weiter damit und machen weiter eine 3. Folge jetzt und zwar sollte es heute um das Prinzip Yakni gehen, was für Gesundheit weißt du ich wusste mal an so n Spiel denken wenn du gewonnen hast wie Yakzi weißt du so yaki? Das ist geil. Aber es steht am Ende für You.
Ain Gone A need it und genau das möchte ich heute gerne mit dir beleuchten, weil es auch ein sehr cooles Prinzip ist, was uns auch öfter begleitet, würde ich jetzt mal so sagen, weil man sich da doch gerne immer mal dran erinnern. Sollte ja genau magst. Du mal sagen was das Prinzip beinhaltet? Genau.
Also es geht im Großen und ganzen darum, dass man unnötige Komplexität vermeidet, also auch gerade Fokus auf Features, die du in den Code einfließen lässt, die aber vielleicht noch gar nicht notwendig sind, also zum Beispiel wenn du sagst, du hast vielleicht irgendwie eine Erweiterung, die du Implementierst, die eigentlich zu dem aktuellen Zeitpunkt noch gar nicht relevant sind, aber vielleicht irgendwann mal
zukünftig möglich wären. Ne, also dass man wirklich sagt, OK, wenn du das vielleicht zukünftig mal brauchst, dann mach es zukünftig und mach es nicht jetzt so, also sozusagen du brauchst das jetzt gerade nicht so ne und ich find da ist so ne so ne kleine Analogie vielleicht mal wieder ganz passend oder ganz interessant und zwar. Und zwar die Analogie vom vom vom Koffer packen.
Also sagen wir mal du machst n Trip ne und sagst jetzt OK ich mach n Wochenendtrip und du guckst auf deine Wetter App und siehst OK es ist nur gutes Wetter so und jetzt könntest du dich natürlich hinstellen und sagen OK. Ich hab nur gutes Wetter, ich pack vielleicht Badehose ein, ich pack kurze Sachen ein und fertig. Das war es aber aint Gonna Need it sozusagen.
Das Jagdny würde jetzt zum Beispiel, wenn du dagegen verstößt, in dem Fall würde jetzt beim Koffer packen, würde durch deinen Kopf gehen, aber was ist wenn es doch regnet, das heißt du packst dir doch noch ne regenjacke ein, das heißt du packst dir doch noch ne lange Hose ein, du weißt ja vielleicht nicht ob die Temperatur doch noch mal abkühlt, aber was ist wenn du mitten in der Nacht doch noch draußen bist und n Pullover brauchst? Und wie ist es denn eigentlich
zum Beispiel mit mit? Regenschirm wenn es vielleicht dann doch noch anfängt zu regnen und solche Sachen. Ne, also diese ganzen Eventualitäten, wo du vielleicht noch sagst und wenn ich jetzt doch noch auf eine sehr schicke Veranstaltung eingeladen werde, ganz toll, ganz.
Toll, nehme ich doch noch. Einen Anzug mit weißt du also solche Sachen, dass du diese ganzen Eventualitäten, die man vielleicht haben könnte, aber in dem Fall einfach ausschließend, sagt Ey, es ist ein Wochenendtrip, es ist gutes Wetter, nimm kurze Klamotten mit, fertig.
Ja. Finde ich eigentlich ein ganz cooles Beispiel, weil ich glaube, das kennt jeder, dass man genau in diese Falle tappt und sich denkt, ah, ich will jetzt auch nicht kalt erwischt werden, dann habe ich nachher die Klamotten nicht bei, weil ich kann es ja dann auch nicht mehr ändern, so nach dem Motto, dann stehe ich da mit meinem kleinen Koffer, habe jetzt keine Regenjacke bei, also es ist ja nicht so, dass man irgendwo noch vielleicht eine Regenjacke
kaufen könnte oder oder einen Regenschirm, auf keinen Fall, also wenn du ihn nicht dabei hast, dann war es das verstehst du also? Ein Beispiel, was ich auf jeden Fall mal habe. Angenommen du bist 3 Tage unterwegs und du würdest sagen du brauchst 3 und aus wie viele packt man eine Hand aufs Herz? Also ich glaube, es gibt wenig Personen, die sich sagen, es sind 3 Tage. Ich brauche jetzt 3 mal Unterwäsche, auf keinen Fall die meisten, die meisten packt doch einfach gefühlt schon das
Doppelte ein. Ja, genau. Aber ich denke. Auch immer. Das wollen wir jetzt nicht diskutieren, aber ne. Es ist, welche Eventualität könnte passieren? Aber OK, lassen wir das, aber das ist auf jeden Fall ein Standardbeispiel bei mir. Ja, aber das kenne ich auch. Es ist bei mir zum Beispiel auch richtig witzig, dass ich immer. Also sagen wir mal 3 Tage und ich würde jetzt 3 t Shirts
einpacken. Ja, es wird niemals bei 3 Shirts bleiben, weil ich immer von dem Fall ausgehe, dass ich mich irgendwie beklecker oder dass irgendwas passiert, dass ich immer noch n ersatzshirt hab. Also ich hab bald. Bei mir so n Ding meistens. Gefühlt ist es so, dass ich sage, ja, ich nehm noch n bisschen mehr mit an Shirts. Und wenn ich wiederkomme, hab ich nicht mal die Hälfte von den
Shirts, die ich mitgenommen hab. Eigentlich immer Faust so nach dem Motto, so viel nehm ich immer mit, also völlig banade aber das ist n typisches jagni Dings, oder? Ja, das stimmt, das stimmt ja. N cooles Beispiel, gefällt mir gut. Ja, also wie können wir das jetzt auf die Softwareentwicklung Münzen? Unseren Koffer ist ja im Prinzip.
Wenn man sagt, You Ain Gone a need it und du konzentrierst dich wirklich und fokussierst dich auf die vorliegenden Anforderungen und ausschließlich da drauf. Das heißt jetzt in dem Kofferbeispiel es scheint die Sonne, ich muss mich jetzt wappnen dafür, dass ich zum Beispiel sommerliche Kleidung hab, dass ich dass mir nicht warm ist den ganzen Tag, dass ich da halt gut durch den Tag komme, so fertig, kein Regen, nichts, das ist einfach jetzt die Anforderung, hab ein Sommeroutfit dabei.
Genau. Und ich mein, wenn man das auf die Softwareentwicklung münzt. Dann ergeben sich halt die Vorteile, die man jetzt eigentlich gut erkennen kann. Weniger Komplexität, weil ich muss nicht so viele Fälle berücksichtigen, das heißt auch in dem Fall, der Koffer ist einfacher gepackt und simpler weniger und genauso wird ja auch dein Code einfacher und auch verständlicher natürlich ne, weil du halt nicht unnötige Funktionen drin hast.
Du bist halt wirklich genau fokussiert auf deinen, auf deine Anforderungen, die du gerade implementiert hast. Und dadurch sinkt halt auch die Gefahr, schon unnötige Komplexität reinzubringen und den Code aufzublähen.
Dass du am Ende sagst, OK, der Stakeholder kommt, hast du es umgesetzt, was ich brauche, ja hab ich aber hier guck mal, weil vielleicht brauchen wir das und das ist auch alles schon drin, dann denkt er sich so OK gut jetzt hat das hier doppelt so lange gedauert als ich eigentlich dachte, weil du schon. 5000 Eventualitäten eingebaut hast, die ich gar nicht wollte, und das ist ja genau das Problem und der Vorteil dann am jakni Prinzip, sich genau darauf zu fokussieren. Genau.
Und es geht jetzt ja auch nicht hierbei darum, dass man zum Beispiel sagt, man reduziert sozusagen die Komplexität einer Funktion ne, sondern man sagt eher so, man reduziert die Komplexität des Codes, weil man bestimmte Funktionen gar nicht erst benötigt, ne, ganz genau, und das bedeutet ja aber am Ende auch, dass man. Nicht nur ein weniger komplexen Code hat, weil man, weil man sozusagen einfachere Funktionen hat, sondern einfach weniger Code hat.
Und das bedeutet ja im Endeffekt auch weniger Code, ist weniger Wartungsaufwand, das ist ja auch ein Vorteil, den man dadurch hat, weil man ja einfach sagt okay, du hast halt weniger potenzielle Fehleranfällige stellen, die du irgendwie in deinem Code drin hast. Also du musst halt weniger vielleicht refecter, du musst weniger Code debuggen, wenn irgendwas auftritt, du hast weniger. Weniger Code, den du auch testen musst, weil wir erinnern uns
testen ist absolut essentiell. Ne, das macht man immer vollautomatisierte. Tests sehr wichtig. Was haben wir denn noch so? Also wir haben auf jeden Fall einen weniger komplexen Code dadurch, das sind definitiv Vorteile, wir haben weniger Wartungsaufwand, das ist auch definitiv ein wichtiger Punkt. Ja, man kann ja sich auch
vorstellen. Angenommen du, du entwickelst das jetzt, weil das, finde ich, ist nämlich auch ein entscheidender Vorteil, du hast das jetzt entwickelt und dich auf diese Anforderungen fokussiert, dann sagst du, ich bin fertig, das heißt also, die Entwicklung ist natürlich dann auch schneller logischerweise, aber gleichzeitig kriegst du ja auch ein schnelleres Feedback dazu, also.
Also du hast es entwickelt und du kannst es ja dann sozusagen zeigen und der, der die Anforderung gestellt hat, also dein Stakeholder sagt Ja ist richtig, oder? Nee warte mal, wir müssen das noch mal anpassen, das muss doch anders sein. Also du kannst natürlich auch, also du hast ne bessere Anpassungsfähigkeit, nenn ich
das mal, weil es ist noch nicht. Unnötig viel da, es ist komplett fokussiert auf die Anforderung und wenn sich da was ändert, weißt du genau, ich muss jetzt das und das anrühren und hab nicht so sag ich mal ungenutzten Code der da gar nicht betroffen ist von ja also was find ich halt auch immer ganz schick
dabei. Was ich zum Beispiel also was ich so was mir in den Kopf kommt als Beispiel, man kennt das ja, wie du ja auch schon meintest, so, es läuft einem ja selber über den Weg, man kennt das ja, du hast vielleicht ne Anforderung wo es heißt OK. Angenommen Du hast ein E Commerce System was du selbst programmierst und sagst.
Du möchtest einen Zahlungsanbieter anbinden, dann könnte man sich natürlich hinstellen und sagen, OK wir wollen jetzt einen zahlungsanbieter A anbieten, anbinden und das heißt du hast irgendwie eine eine API mit der du an mit der du. Quasi gegen die du gegen Implementierst ne so und dann könnte man natürlich relativ schnell auf die Idee kommen und sagen ja, aber Pass auf, wir haben ja jetzt wahrscheinlich, also wahrscheinlich gibt es in
Zukunft noch mehrere an Zahlungsanbieter, zum Beispiel zahlungsanbieter B und C, die wir auch noch anbinden wollen, also implementier ich schon mal n Interface, dass man im Endeffekt irgendwann später ne, das ist jetzt wieder genau dieses, diese dieser Keypunkt an der Stelle ne, also dieser.
Beziehungsweise so n Warnzeichen wo man sagen könnte, OK das vielleicht später ne genau das dieser Gedankengang später könnte man das ja noch gebrauchen, dass man dann im Endeffekt sagt, OK, ich muss ja momentan nur diesen einen Anbieter anbinden und wir wissen noch gar nicht welche dazu kommen und wir wissen noch gar nicht, ob überhaupt noch andere dazu kommen und wir wollen jetzt erstmal.
NE Commerce System haben wo man sagt wir wollen jetzt überhaupt erst mal was verkaufen und dazu brauchen wir irgendwie n zahlungsanbieter und damit das funktioniert muss man noch nicht n Interface schreiben um zu sagen OK vielleicht dieser Anbieter dieser Anbieter oder dieser Anbieter, sondern sagt erst mal OK wirklich Fokus nur auf den einen ne.
Ja. Finde ich ist n gutes Beispiel erstmal um zu zeigen, dass also wo Jagd nie hingeht und wo man schnell quasi da ausbricht, weil es ist halt auch n fantastisches Beispiel um mal auf Nachteile einzugehen, weil ich glaub die Vorteile sind eigentlich relativ klar, aber es ist ja nicht immer alles nur schöne Heide Welt. Also man kann ja mit Jagd nie auch in ne gewisse Falle laufen, wenn man es zu streng verfolgt.
Ja. Und ich finde, du hast da gerade ein gutes Beispiel gebracht, wo man sich wirklich überlegen muss, ist das jetzt, also gehe ich jetzt streng nach Jagni und Code zum Beispiel diese diese API Anbindung für den Zahlungsanbieter so richtig straight runter schlicht gehalten sage ich mal oder überlege ich mir vielleicht doch schon eine Struktur die skalierbar ist? Klar, ich würde Jagni verletzen, wenn ich sage ich baue noch.
Sag ich mal nen Frame drumrum um es skalierbar zu machen in Zukunft. Aber das ist auch n Fall wo man eigentlich schon ziemlich genau weiß, es muss skalierbar sein später, weil du wirst mit einem Produkt oder mit sagen wir mal mit deinem E Commerce System was du meintest ja schwer ins Ziel komm später wenn du nur einen zahlungsanbieter anbindest. Also das ist ja eigentlich schon relativ klar, dass.
Dass du weitere anbinden musst. Und dann finde ich, ist das nämlich ein Nachteil von Yagni, dass du sagst, okay mir muss bewusst sein, wenn ich diesen Weg jetzt gehe, dass ich später mehr Arbeit habe, also einen erhöhten Aufwand, dass alles zu refact dann und dann auf eine skalierbare Lösung umschalte, wenn ich weiß quasi, dass ich das brauchen werde, und das ist so ein Trade Off und wie immer bei so einem Code Prinzip, und das hatten wir auch bei den anderen.
Ist es halt ne Balance die man da halten muss, weil an der Stelle würde ich jetzt zum Beispiel sagen, hm, es lohnt sich schon auf ne skalierbare Lösung direkt zu gehen, zum Beispiel dass du n Interface machst, dass du sagst, OK, ich kann jetzt mehrere Zahlungsanbieter integrieren in mein System oder in meine Software, würde an der Stelle halt schon Sinn machen das vorzubereiten und.
Weil ich halt einfach weiß, OK, ich muss einfach mehrere anbieten, weil sonst wird dieser E Commerce, also das E Commerce System nicht wirklich Abnehmer finden, weil ich mein heutzutage ist die Erwartungshaltung einfach klar. Ich möchte paypal haben, ich möchte Kreditkarte haben und whatever ne, also dass einfach mehrere Möglichkeiten da sind und das finde ich ist deswegen n fantastisches Beispiel von dir um einfach auf diese Balance mal hinzuweisen.
Ja, auf jeden Fall. Also gerade wenn du sagst, also ne mögliche Mehrarbeit kann durchaus dadurch entstehen,
hundertprozentig. Und ich, ich finde, das ist halt auch genau die eine weitere Schwierigkeit, die da ein bisschen mit einhergeht, weil wenn du wirklich sagst, ich arbeite immer und nur ganz strikt nach Yagni, dann kann es dazu führen, dass irgendwie diese Weitsicht fehlt, ne, dass man halt vielleicht wirklich an manchen Stellen mal sagt, was muss denn aber wo soll es denn in Zukunft hingehen, weil strikt immer nur zu sagen, ja, aber jetzt also wirklich mal, ich
übertreib jetzt und so ein bisschen. Sag ich mal provozierend gesagt, wenn man nur von der Tapete bis zur Wand denkt, dann kommt man ja auch meistens nicht wirklich weit. So, und da muss man dann wirklich und ich finde es gut, dass du das gesagt hast, diesen, das ist ein Trade off, weil ich finde das auch so schwierig, weil ich hatte das auch schon mal, dass ich dann mit einem.
Kollegen Imper Programming Imper Programming im Programming im Programming du. Bist immer noch auf dem Oktoberfest. Imper Programming.
Mit einer also wir haben, wir haben programmiert und ich mein, ich hatte dann halt so gesagt, so ja, aber guck mal wenn wir ich ich weiß nicht mehr genau worum es ging, aber ich hatte so n so n weiterführenden Gedanken ne und dann hieß es gleich so ja aber jakni so brauchen wir noch nicht ne denk doch dran also wir es ist ja jetzt noch gar nicht notwendig und. Und dann sind wir so n bisschen in so n Gespräch gekommen, dass
ich mir so dachte. Also ich dachte also meine Position war na ja, aber denk doch mal da dran, es wird ja sehr wahrscheinlich schon kommen und seine Position war ja es wird kommen vielleicht du weißt es nicht genau und es ist in der Zukunft und das war halt so ich weiß auch nicht genau jetzt wer jetzt recht gehabt hat, darum geht es jetzt auch am Ende nicht, ob es jetzt sozusagen noch gemacht wurde oder nicht, aber ich finde, dass es durchaus.
Sinnvoll ist, genau dieses Gespräch zu führen. Weißt du was ich? Meine das zu challengen.
Dann genau um dann auch einfach darüber zu diskutieren, einfach nur zu sagen, ja yakni oder ja, wir machen das jetzt und ich sag mal Scheiß auf Yakni sozusagen ist ja dann auch irgendwie blöd, also einfach nur zu sagen ja, also ne, wenn man jetzt zum Beispiel angenommen man programmiert und jemand sagt Yakni und jemand sagt, Oh ja klar ach stimmt, der ist ja so Weise und gebildet dieser Mensch, weil er yakni gesagt hat so. Er hat auf jeden Fall recht.
Also da muss man natürlich dann einfach mal gucken und sagen okay macht es Sinn oder macht es nicht. Also genau diesen Trade auf auch vielleicht mal ein bisschen anzudiskutieren, das ist glaube ich dann auch auch wertvoll, weil am Ende kann es ja natürlich dazu kommen, dass du dann, wenn du das hast, du ja oftmals, wenn du sagst, man implementiert erstmal nur die, die die einfache Lösung muss, dann vielleicht aufgrund von vielleicht fehlender Weitsicht
noch was. Nachimplementieren, du hast also diese Mehrarbeit und dann kann es dazu ja durchaus noch führen, dass du zu dem, dass du diese Mehrarbeit hast, auch noch refactoring drumherum machen musst. Ja, ja ne, das ist ja dann noch mal so n so n so n dritter Nachteil, der dann theoretisch auftreten könnte.
Ja ja, guter Punkt. Gerade wenn du denn zum Beispiel sagst, OK, nee, ich mach jetzt ganz strikt jagni und ich verzichte auf saubere, modulare Strukturen, obwohl ich eigentlich schon weiß, dass ich das brauchen werde später. Dann habe ich halt einfach einen sehr hohen refactoring Aufwand, wie du gerade schon meintest am Ende und das muss einem dann halt auch bewusst sein, sozusagen. Aber trotzdem ist es ja ein gutes Prinzip.
Also klar, wir müssen auf die Nachteile eingehen, aber es hat natürlich auch die Vorteile, die wir genannt haben und was würdest du denn sagen, wann ist es denn sinnvoll nach dem jagni Prinzip zu arbeiten oder wann ist es für dich auch aus deiner Erfahrung heraus sinnvoll gewesen? Ja, also definitiv. Ich weiß, worauf du hinaus
willst. Das ist nämlich, also ist ja wirklich ein super spannender Punkt und ich, also ich würde sagen, ein ein ganz klassischer Anwendungsfall von Jagd nie wäre, wenn man unklare oder unsichere Anforderungen hat. Also wenn du ein Produkt entwickelst, wo du sagst, ich weiß eigentlich noch nicht so hundertprozentig, wo es hingeht, also du hast noch eine sehr hohe Flexibilität.
Ja. Und. Und du weißt einfach noch nicht genau, wo dieses Produkt im Feature Set nenn ich das jetzt einfach mal terminiert ne und was vielleicht auch gut ankommt beim User ne, also wenn du. Ja, das ist n sehr wichtiger Punkt. Genau. Also wenn du halt einfach noch diese hohe Variabilität. Drin hast. Genau, und da kannst du dann im Endeffekt einfach.
Also wenn wenn du halt diese Anforderung hast und vielleicht userwünsche kommen rein und das heißt ja, wir wollen das vielleicht doch so und so haben, oder das ist gut, das ist noch nicht so gut, dann kannst du ja, wenn du. Erstmal minimale Ansätze implementiert hast, also nach diesem jagni Prinzip gearbeitet hast, kannst du natürlich auch schnell auf solche Änderungen reagieren, weil du halt eben noch nicht so ne hohe Komplexität hast, weil du bessere Anpassungen machen kannst.
Ne und? Das hilft an diesen Stellen natürlich, das heißt, Jagni ermöglicht in solchen Momenten natürlich, flexibel zu bleiben und in gleichzeitig noch Ressourcen zu sparen, weil du ja noch nicht so viel im Voraus implementierst, ne? Das wäre auf jeden. Fall ein super Anwendungsfall meiner Meinung nach. Ja, ich finde es halt auch wichtig, wie du gesagt hast, wenn so noch die Userwünsche sich ändern oder unklar sind.
Oftmals ist es ja auch so. Du hast so ne Produktidee, aber musst deinen Platz im. Im Markt sag ich mal noch finden. Du weißt noch nicht so wirklich wo deine Nische vielleicht ist, wo du dich platzierst mit deinem Produkt und dementsprechend können sich auch die Anforderungen noch drastisch ändern, wenn du auf einmal merkst ey ey, weil ich hab warte mal. Ich hab eigentlich ne ganz andere.
Zielgruppe die da drauf. Also die davon angesprochen sich fühlt sozusagen ne und dann ändern sich wahrscheinlich auch die Anforderungen noch mal. Und das ist halt gerade so in frühen Phasen von Projekten. Super. Entscheidend, dass du denn halt auch schnell reagieren kannst, wie wir ja vorhin meinten, dass du halt schnell Anpassung machen kannst und dafür ist das jagni Prinzip wirklich gut und in dem Zusammenhang, ich glaub das haben wahrscheinlich viele schon
gehört. Gibt es ja auch dieses typische MVP Prinzip, also Minimum viable Product glaube ich. Ich bekomme immer bei der Ankürzung mal ein bisschen durcheinander, dass du sagst okay, ich versuche jetzt das kleinstmögliche funktionsfähige Produkt meiner Idee zu bauen und schmeiß das sozusagen erstmal auf den Markt und gucke, was ich für ein Feedback Kriege und das in Kombination mit Jagni.
Harmoniert halt super, weil du denn wirklich fokussiert bist, dieses kleinstmögliche Produkt zu erschaffen, dass du dir überlegst. Was sind so die mindestens also, die das Minimum an Features die ich brauche um erstmal n Feedback zu kriegen, ob überhaupt meine Idee gut ankommt. Genau also das minimale Featureset, damit das Produkt lebensfähig ist.
Sozusagen ne genau. Ja, das und dass du halt auch wirklich NN, also sag ich mal sinnvolles Feedback bekommst, dass du auch wirklich sagst, OK, das geht jetzt in die Richtung von. So n Featureset wie meine Idee ist. Ja, also es. Ist ja jetzt nicht sag ich mal. Ich möchte ne App entwickeln und hier hast du jetzt ne ne App die startet und da ist n Button, da kannst du drauf klicken. Also es muss ja schon deine Idee verkörpern, aber halt in dem kleinsten Umfang.
Ja genau, also du. Es hilft halt einfach, den Fokus auf das Wesentliche zu halten, um dann sozusagen das Produkt zu entwickeln. Und was ich immer, was ich schwierig finde, was ich noch mal irgendwie n bisschen einordnen möchte, ist, dass. Produkt und User ne. Ich finde da denkt man immer relativ schnell an alles was so momentan in im im App und Webbereich unterwegs ist.
Aber selbst wenn du ne Maschine programmierst oder irgendwie nen Mikrocontroller programmierst der irgendwo ne Maschine kommt die dann irgendwo arbeitet in der Fabrik, dann ist der User der Besitzer der Fabrik. Sozusagen weißt du, also der Mensch der sozusagen in seiner Fabrik dieses Teil dann nutzt.
Also nur, dass man es noch mal einordnet, weil ich find selber immer wenn man daran denkt und sagt, OK, was ist denn denn, wenn ich an User denke, dann klingt das für mich immer gleich so wie der End User der irgendwo an einem Telefon sitzt und es bedient, aber es geht ja immer um den Menschen oder die Personen Zielgruppe, was auch immer die dann am Ende dieses Produkt, was auch immer es ist, benutzt, benutzt oder genau ja.
Wichtiger Punkt, dass man da also auch mal vom vom Mindset mal wirklich an alle Bereiche denkt und trotzdem kannst du diese. Prinzipien oder auch das MVP Prinzip oder MVP sagt Man Prinzip, also MVP auch dafür bauen, das ist halt und dann kannst du genauso wie mit Jagni das Halt iterativ immer verbessern und wenn du merkst das kommt gut an und du kriegst Feedback kannst du das
einarbeiten. Du kannst weitere Features hinzufügen und hast dann eigentlich eine sehr geile Position dein Produkt immer besser und umfangreicher zu machen, genau weil du ja weißt es kommt gut an.
Genauso kann es ja auch sein, dass du wirklich komplett dran vorbei entwickelt hast und nicht deine Position im Markt sozusagen findest, weil der Anwender oder der User dann sagt, Nee, soll ich mir das nicht vorstellen, das hilft mir gar nicht, aber das natürlich auch, aber dann kannst du quasi noch mal komplett das neu überdenken. Ja und anders an die Sache zum Beispiel rangehen, neuen MVP
bauen, warum nicht? Aber das ist auch n finde ich n sehr guter Punkt, weil wenn User zum Beispiel ne, also der der Anwender am Ende. Wirklich an den Punkt kommt, wo er sagt, Nee, das habe ich mir so aber gar nicht vorgestellt, dann kann das unter Umständen zum Beispiel auch daher rühren, weil ich finde, das ist, wenn du so ein MVP entwickelst und du verstößt gegen Jagd, nie ist zum Beispiel ein Verstoß oder ein Resultat, wenn du dagegen verstößt, sowas wie zum Beispiel
angenommen, du hast. Weiß ich. Jetzt muss ich natürlich wieder auf App und Web anwendungsebene gehen, damit man sich das besser. Vorstellen. Die Fabrik. Damit man sich das besser vorstellen kann.
Aber sagen wir mal, du hast ne, du hast ne Tabelle die du sortieren willst oder was auch immer und dann überlegst du dir, wie würde der User das denn gut finden, wie die zum Beispiel sortiert wie man die sortieren könnte, also dieses du du holst dir nicht das Feedback sondern du überlegst selber wie das sein könnte, implementierst es dann also.
Implementierst etwas, wo du noch gar nicht weißt, ob es benötigt wird und dann hinterher kriegst du das Feedback wo es dann heißt ja nee, aber ich weiß nicht, dass das so will ich das gar nicht haben und dann musst du es noch mal implementieren, einfach nur weil du an etwas gedacht hast. Was was du vielleicht, was vielleicht benötigt wird oder vielleicht cool gefunden wird, aber du weißt es eigentlich nicht, also mach es nicht, dann würde ich eher sagen.
Lass diese Tabelle so wie sie ist, ohne dass sie sortiert werden kann. Und wenn der User dann hinterher sagt ich brauch die aber unbedingt, dass sie sortiert wird, dann fragst du wie und dann sagt er dir ja alphabetisch und dann machst du das und fertig ist der Bums. So ne also kleines einfaches Beispiel natürlich ist nicht immer so Straight Forward, aber in die Richtung würde es gehen, wenn man zum Beispiel gegen Jagd nie verstößt. Eine Möglichkeit, ein mögliches Resultat.
Und das kann halt sehr viel Zeit am Ende kosten. Genau plus längere Feedback schleifen, weil du wahrscheinlich also sagen wir sind wir mal ehrlich, wenn du anfängst dir zu überlegen wie es sortiert werden könnte, ist die Wahrscheinlichkeit jetzt echt nicht gerade klein zu sagen, OK ich bau einfach schon mal so 34 Sortiermöglichkeiten ein, die kann man denn auswählen und so weißt du und dann denkt er sich, der hält dann wenn er nee sortier ist einfach alphabetisch
und fertig. So beispielsweise, und das ist halt genau die Falle, dann am Ende wieder. Jetzt lass uns mal noch über den Punkt reden, wir haben jetzt quasi besprochen, wann jagni gut ist es einzusetzen, aber es hat wie immer auch seine Grenzen, wo man vielleicht sagen sollte, jetzt nicht mehr so Straight nach Jagni fällt dir da was ein? Also du meinst wo man jetzt vorsichtig sein sollte, wo man das jetzt einsetzt. Ja, zum Beispiel.
Genau also. Also wo man wo man einfach sagen kann, Oh, jetzt strikt nach jagni werden nicht mehr so gut.
Also zum Beispiel, wenn also eigentlich, wenn man jetzt sagt, okay, man hat, also, wir gehen jetzt vom MVP weg, man will jetzt nicht schnell ein Produkt sozusagen auf den Markt werfen und ausprobieren, wie das ankommt, um sich sozusagen einzuordnen, wo es hingehen soll, sondern du hast eigentlich natürlich jetzt eher so ein bisschen das Gegenteil, du hast Feste. Zielsetzungen du weißt okay das und das soll das Ergebnis sein und du weißt eigentlich auch
schon, was gewünscht ist. So ziemlich genau. Und du hast vielleicht auch sehr komplexe Projekte oder große Projekte, wo es dann einfach wichtig ist, dass du sozusagen bestimmte dieses, dieses, dieses, diesen Weitblick nicht ignorieren darfst. Weil sonst halt einfach zu unglaublich teuren refactoring Phasen führen kann und so ne.
Also wenn du wirklich weißt, das ist ein komplexes System und du weißt wo dieses komplexe System irgendwie worauf worauf also wo das Ziel dieses Systems auch irgendwo liegt. Also genau, wenn du einfach sag ich mal einen konkreten Fahrplan hast und dann zum Beispiel schon, gehen wir noch mal auf das E Commerce System ein was du meintest. Wenn dann aber schon quasi in den Anforderungen steht ich brauche zahlungsanbieter ABC und d, dann würdest du ja nicht noch
überlegen. Ja ich implementier jetzt aber gerade a und jetzt mach ich so straight wie möglich und so schlicht wie möglich und danach mach ich b und dann refect ich das alles wieder, dann würdest du dir natürlich im Vorfeld wie wir vorhin besprochen haben, dir schon ne skalierbare Lösung überlegen um viele. Zahlungsanbieter anwenden zu können. Am Ende, das ist, finde ich, um das Beispiel noch mal aufzugreifen.
Das ist, finde ich, auch ein ein sehr, sehr guter Unterschied, weil das eine ist, lass uns das schon mal implementieren, weil vielleicht brauchen wir es später und das andere ist, lass uns das, wir können das jetzt schon implementieren, weil es ganz sicher zu 100% später schon einfach. Kommt, weil da die Unsicherheit dann einfach raus ist, quasi
also die Zukunft ist klarer. Ich will jetzt, ich würde jetzt niemals behaupten, sie ist zu 100% klar, weil ich mein jeder, der in realen Projekten gearbeitet hat, kennt das. Es wird sich noch mal was ändern, definitiv also selbst wenn du das Gefühl hast, es ist komplett klar was wir hier also auf der Zielgeraden irgendwann mal haben als Produkt, es wird sich was ändern, also es ist nicht ausgeschlossen, aber wenn es so klar ist, dass du weißt. Es ist zu 99%.
Wären wir also, sagen wir mal zu 100% mehrere Zahlungsanbieter und zu 80% ist schon klar welche, dann würdest du ja trotzdem anfangen das zu skalieren, sozusagen. Dann kann es sein, dass du vielleicht mal n zahlungsanbieter rausschmeißt oder einen ergänzt, OK, aber trotzdem würdest du ja dann halt schon anders an die Sache herangehen, als würdest du sagen, es kann sein, dass es nur einer ist. Also mach ich jetzt nach Yagni auch wirklich nur den einen. Ja, genau.
Aber zum Beispiel, wenn du jetzt also ne, wir haben jetzt diesen Zahlungsanbieter mal als Beispiel genommen oder dieses E Commerce System und das ist natürlich aber auch unter Umständen ne klar, da fließt auch Geld und so, aber es ist jetzt vielleicht noch nicht ganz so kritisch, aber wenn man jetzt wirklich in in andere Bereiche reingeht, wie zum Beispiel irgendwie luftfahrtmedizin oder so ne, das sind ja auch Sachen wo man wirklich im Vorfeld schon.
Bestimmte Szenarien einfach sehen sollte und die im Vorfeld schon einkalkulieren sollte. Also wirklich diesen Weitblick zu haben, um zu wissen, was muss, was muss denn da passieren, was muss denn da passieren, wenn wir das machen? Ne, also einfach zu gucken, du willst nicht, dass dein Flugzeug hinterher abstürzt, weil sozusagen ja erstmal war doch nur gedacht, dass es starten kann, also landen ist doch erstmal egal, so ne. Weißt du also man ey.
Ja OK, gut, das falsch. Also sowas funktioniert ja dann nicht, ne und und deswegen muss man da natürlich schon deutlich separieren und sagen, wenn du in dem in einer gewissen Komplexität arbeitest, wie zum Beispiel auch ne in solchen Luft und raumfahrtsystemen Medizin oder so wo wo halt wirklich Gesundheit und vielleicht auch Menschenleben davon abhängen was da los ist, ist das natürlich noch mal eine andere Geschichte, ne und im Normalfall. Ja, also.
Absolut. Wenn du jetzt sage ich mal, wenn weil du meinst Luft und Raumfahrttechnik Bahntechnik auch in der automobilen Welt, wenn du da natürlich sicherheitskritische Systeme hast, dann hast du ja automatisch verschiedene ISO Normen die quasi klassifizieren welches sicherheitskritische Level du hast. Und dann folgen darauf ja Prozesse die du einhalten musst. Beispielsweise auch in der Entwicklung.
Und dann wird es halt auch schwer zu sagen, nee, jagni mach ich jetzt nicht, ich mach jetzt hier wirklich nur das was die Anforderung ist, die ich gerade entwickel, das wird halt schwierig, weil dann wirst du an den Punkt kommen, wo du sehr viel noch mal umbauen musst, weil du halt gewisse Prozesse dann einfach nicht einhältst und das ist definitiv so, dass da jagni schwierig wird. Also du kannst es bis zum gewissen Grad halt umsetzen, dass du sagst, OK, ich will
jetzt wirklich. Rein funktional sag ich mal nur dieses Feature implementieren, aber die Welt die da drum entsteht durch Prozesse, die du beispielsweise durch ISO Norm aufgedrückt bekommst es mal bisschen provokativ zu formulieren wirst du einhalten müssen und dann macht es keinen Sinn sie zu ignorieren und später super viel ja Nacharbeit zu haben, also refactoring Aufwand überarbeitungsaufwand also. Super Beispiel, weil da wirst du
nicht drum rum kommen. Aber gerade ist ja auch gut, dass du nicht drum rum kommst, weil sonst hast du nachher im Flugzeug was starten kann und nicht klar. Aber gerade auch sowas wie solche Normen.
Damit gehen ja dann unter Umständen auch bestimmte Architekturentscheidungen einher, die einfach nicht notwendig sind dafür und die kannst du dann im Endeffekt nur, weil du dann sagst, ja ja nee, Obacht brauchen wir noch nicht, ja vielleicht braucht man das zu dem Zeitpunkt, wo man das Projekt aufsetzt und startet noch nicht, aber du weißt. Du brauchst es aber in Zeit x ne und da muss es da sein. Also wieso nicht von vornherein das so aufsetzen?
Ne, also wie wie du meintest du hast genau dann irgendwann kommst du an den Punkt und dann hast du vielleicht ne riesige riesige refactoring Arbeit wo jeder sich hinstellen würde und sagen würde ey das Wusstet ihr doch von vornherein schon, wieso habt ihr das nicht gleich gemacht? Ne und das ist natürlich. Genau dieser Trade auf und ich find es aber auch unglaublich schwierig, wenn man selber an dem Projekt arbeitet, an welche trotzdem.
Also es ist ja ne, man kann sich das so hinstellen und sagen OK pass auf so und so ist es ne so und so wird es so und so grenzen wir das jetzt ab und da ist es gut, da ist es schlecht aber nichtsdestotrotz kann man ja sagen, dass es immer wieder trotzdem finde ich zumindest persönlich für mich gar nicht so hundertprozentig die diese Antwort gibt zu sagen. Machen wir das jetzt schon oder noch nicht?
Also man struggelt trotzdem ab und an immer mal wieder finde ich, mit dieser Entscheidung sollte man das jetzt umsetzen oder lieber doch nicht, weil man braucht es ja noch nicht, aber aber vielleicht doch, aber sehr sicher doch, oder? Also es ist ja immer diese gewisse Unsicherheit wie du meintest, es ist ja nie ein absolut ein, also die Zukunft ist ja nie gewiss, um mal ein bisschen philosophisch zu gelingen, aber. Aber man war das philosophisch.
Aber die Frage ist halt, wie wahrscheinlich oder wie unwahrscheinlich ist es und und und. Diese Varianz, die dazwischen irgendwie einhergeht, das ist halt so, das ist dann so dieses Fingerspitzengefühl, wo man sagen kann, OK, ist es jetzt gut oder nicht, da struggle ich persönlich auch manchmal noch es. Ist ja so jakni oder nicht jakni, das ist hier die Frage, ne. So, jetzt klage ich auch mal n bisschen philosophisch. Sehr gut also. Nein, aber oder nicht. Ja, ja klar, klar.
Deswegen haben wir auch vorhin gesagt, das ist ne Balance, weil es ist ja quasi nicht sozusagen binär an aus, also jagni ja, jagni Nein, sondern. Du hast einfach fließende Übergänge und ne Balance, die du schaffen musst. Mal kannst du sagen, OK, ich fokussier mich dann doch mehr auf diesen jakni Ansatz, weil es an der Stelle einfach gut funktioniert oder wir vielleicht noch früh im Projekt sind.
Alles was wir so beleuchtet haben genauso kann es zur anderen Seite kippen, wenn wir beispielsweise in einem sicherheitskritischen Projekt arbeiten und Prozesse einhalten müssen oder weit fortgeschritten sind, auch in der Produktkomplexität am Ende, dass du das dann halt auch nicht mehr
so einfach machen kannst. Also es ist halt wirklich wieso ne Waage und man muss halt gucken und für sich entscheiden und ich glaub da spielt auch irgendwann ne Menge Erfahrung rein, die dir dabei hilft das zu entscheiden was jetzt der bessere Ansatz ist. Am Ende wie gesagt, Es hat ja immer vor und Nachteile genau wie die anderen Prinzipien die
wir schon erklärt hatten. Das ist n guter Stichpunkte, weil ich ich find das auch noch mal interessant, weil man kann sich ja natürlich jetzt hinstellen und sagen, OK, pass auf, ihr hattet jetzt andere Prinzipien wie Dry und Kiss hattet ihr schon genannt, da ging es ja auch irgendwie so n
bisschen darum zu sagen. Macht das nicht doppelt, also ne Komplexität vermeiden oder was ne oder sowas wie macht es einfacher, also Komplexität vermeiden und jetzt habt ihr auch wieder von Komplexität vermeiden geredet. Also es ist jetzt im Endeffekt alles das gleiche, aber um das noch mal vielleicht n bisschen abzugrenzen, es ist ja nicht.
Genau das gleiche, weil diese, wenn man das jetzt wirklich auf den Punkt bringen möchte, gibt es ja unterschiedliche Ziele von den unterschiedlichen Prinzipien. Also wenn du das Drive Prinzip nimmst, dann hast du halt das Ziel Redundanzen im Code zu vermeiden, im groben ne wenn du Kiss nimmst. Als Prinzip geht es ja darum wirklich Software zu vereinfachen oder einfach zu halten, gar nicht erst komplex zu machen.
Und wenn du Jagni nach Jagni arbeitest, versuchst du ja unnötige Features, die vielleicht in Anführungsstrichen in der Zukunft irgendwann mal notwendig sind, im Vorfeld zu vermeiden oder genau diesen diese Gratwanderung zu machen. So brauchen wir es, brauchen wir es nicht und dann halt genau nach Erfahrung eben diesen Schritt zu machen oder halt eben
nicht. Und das sind ja genau also, um das noch mal abzugrenzen, ne, dass du wirklich sagst, so Dry und Kiss konzentrieren sich auf die Struktur und Lesbarkeit des Codes und Yagni ist halt so der Fokus auf die Umsetzung von Features und deren Notwendigkeit, ne, um das noch mal n bisschen abzugrenzen. Liebe zürerin lieber zürer, wenn du jetzt gerade sagst, ey, ich ist die 1.
Folge von von euch die ich höre, wir hatten schon 2 alte folgen, hör da mal rein dry und Kiss. Sind auch sehr gute Prinzipien, die einem weiterhelfen können. Auf jeden Fall und die man auch immer mal im Hinterkopf haben sollte, aber ich fand das war n sehr gutes abschließendes Wort und ich glaube wir haben jetzt japni ich find den aber immer noch so geil, ausführlich besprochen und auch gut beleuchtet mit vor und Nachteilen und wann man es einsetzen kann oder besser nicht
sollte. Deswegen würde ich sagen würde ich jetzt die Folge hier beenden, wenn das für dich OK ist, fabi. Das passt.
Und deswegen noch mal der Appell an dich, liebe Zuhörerinnen, liebe Zuhörer, falls dir das Projekt Coding Buddies gefällt und du diesen Podcast magst, lass doch gerne auch mal ein Feedback da Like auf den gängigen Plattformen unseren Podcast empfehlen auch gerne weiter und wenn du Bock hast, findest du in den Show Notes auch einen Link, da kannst du spenden, das würde uns mega freuen, das hilft uns hier auch alles noch zu verbessern und fortzuführen, denn wir haben
weiterhin extrem Bock auf diesen Podcast und das Projekt Coding Buddies. Zu unseren anderen Plattformen, wenn du da mal vorbeischauen willst, findest du ebenfalls in den Shownotes. Schau da gerne mal vorbei, join auch gerne unseren Discord Server, da sind wir mittlerweile eine sehr coole Runde und diskutieren über Softwareentwicklung und allgemeine Themen.
Ansonsten würde ich sagen, beenden wir jetzt die Folge hier, wir hören uns alle beim nächsten Mal wieder und bis dahin hab eine gute Zeit, wir hören uns deine Coding Boys. Gemeinsam besser.