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.