Wir haben ja schon oft über Dinge wie MVP oder Yagni
gesprochen und im Endeffekt hat es alles immer das gleiche Ziel.
Man versucht erstmal 80% Lösungen zu schaffen, die
erstmal das Projekt Weitertreiben, doch bedeutet 80%
Lösung auch 80% Softwarequalität?
Genau darum geht es heute in der Folge Coding Buddies, Dein
Podcast rund um Softwareentwicklung und
aktueller Tech News. Herzlich Willkommen.
Einen wunderschönen guten Tag und herzlich Willkommen zur
neuen Folge vom Coding Buddies Podcast.
Es soll ja nicht fehlen, eine neue Folge für die neue Woche
und zwar mit mir, mit Fabi. Und dem Tino.
Er sitzt mir gegenüber, er ist bereit, ich hoffe, er ist
bereit. Tino, Was geht ab sowas von
bereit, was geht ab fabi, was geht ab, was geht down ja ich
mein Wir werden es jetzt auch regelmäßig gefragt, das
etabliert sich ja gerade so n bisschen.
Gerade auf Twitch. Deswegen muss ich das hier auch
einfach weitertragen, ne ob es auch down geht.
Ja es ist einfach, das ist so Old School, das ist einfach
wieder angesagt jetzt alles kommt Wasser, alles kommt
wieder. Ja wir hatten ja schon die
Skaterhosen ne die Baggies von früher na ja klar hatten wir
erst vor kurzem und deswegen alles alles hat wieder mal seine
Zeit, alles hat ein Ende nur die Wurst hat 2 ja nee das ist
wieder was anderes ja aber es greift hier auch genau.
Tino, Ich würd mal sagen wir starten n bisschen bevor wir
richtig reinstarten. Ne würd ich mal ganz kurz da
will ich ganz kurz noch mal sagen, wir haben uns ja das das
Schöne bei einem Podcast ist. Ja man kann sich immer so n
bisschen so auch n paar Statistiken angucken ne und wir
haben. Wir lieben Statistiken, wir
lieben, Wir sind IT ler, wir lieben Statistiken.
Ganz genau. Und wir haben jetzt mal gesehen,
dass ungefähr ne n bisschen mehr als 50% der Leute unseren, die
unseren Podcast hören. Noch gar nicht unseren Podcast
abonnieren beziehungsweise ich sag mal Follower sind ne, also
folgen ne genau folgen und deswegen wollte ich einfach nur
mal ganz freundlich daran erinnern.
Ja, dass es auf jeden Fall supergeil ist.
Also erstmal verpasst ihr quasi keine neue Folge und für uns ist
es natürlich ne super Sache für den Podcast, auch wenn ihr
einfach n Follow da lasst. Also macht das gerne.
Genau, es kostet nichts, es tut nicht weh und hilft uns
ungemein. Also, liebe Zuhörer, liebe
Zuhörer, falls du auch noch nicht folgst, dann ganz kurz mal
aufs Knöpfchen drücken, das würde uns mega supporten.
Dann vielen vielen Dank dafür an dieser.
Stelle ganz genau und ansonsten falls es gibt auch in den
Shownotes noch n spendenlink falls du schon folgst und sagst
ey ich möcht mal was zurückgeben gibt es auch n kleinen
Spendenling, da kannst du uns auch mit unterstützen auch sehr
lieb von dir aber Tino Ich würde sagen jetzt kommen wir mal zur
Folge. Halt zur heutigen, auch zum
heutigen Thema. Und wie fangen wir das Ganze an?
Ja also ich würd mal ich will dich mal fragen und ich frag
jetzt einfach mal so in die Runde ob man sowas schon gehört
hat also mir geht es schon so, dass und ich hab mich auch schon
mit der ein oder anderen Person noch mal unterhalten, dass man
schon mal so n bisschen jetzt in letzter Zeit hört oder das ist
so wie sagt man das ist so n ist so im Umlauf weißt du dass man
sagt Mach doch erstmal ne 80% Lösung?
Ja und nicht gleich ne 100% Lösung.
Vielleicht gibt es das auch schon länger, ne aber für also
ich weiß nicht so, ich hab das Gefühl das kursiert gerade
wieder so n bisschen möglicherweise auch vielleicht
so n bisschen, ich sag mal wirtschaftlich bedingt ne man
sagt ja ne man muss ja dann auch quasi gerne in der Wirtschaft
soll es vorangehen, schnell, schnell, schnell so nach dem
Motto Man muss ja wettbewerbsfähig bleiben und
deswegen wird dann gerne mal der Beruf.
Laut macht doch erst mal 80% ne, also noch nicht die 100% Lösung
so in 80%, deswegen wollte ich mal fragen, kennst du das?
Und auch in die Runde? Ja das kann ja jeder mal für
sich mal überlegen, ist einem das in letzter Zeit mal über den
Weg gelaufen oder nicht? Mhm, also ich glaube, das gibt
es schon ziemlich lange, also auch in sämtlichen Lehrbüchern.
Es gibt ja auch verschiedene Dinge, die einfach genau in
diese Kerbe schlagen. Ja, also wir haben ja.
Über sowas wie Jakni gesprochen beispielsweise.
Wir haben über MVPS gesprochen und die haben ja oft steckt da
ja n gemeinsamer Grund dahinter zu sagen, wir wollen erstmal
irgendwie progress haben, ne und auch vor allem so agile Gedanken
oder auch so Death Ops Mindset, alles was wir so besprochen
haben im Podcast, ja greift da irgendwie.
Mit rein, weil du sagst, OK, was ist der Vorteil, wenn wir das so
machen, ja, dass wir beispielsweise n schnelles
Feedback kriegen, ja entwickeln wir überhaupt in die richtige
Richtung oder oder laufen wir komplett in unterschiedliche
Richtungen? Ne, sagt der Stakeholder am Ende
ja genau so hab ich es mir vorgestellt oder Leute was habt
ihr die letzten 6 Monate gemacht?
Ne jetzt hab ich zwar ne 100% Lösung aber die Fittet überhaupt
nicht mein Need so am Ende ne also ich brauch das nicht sieht
gut aus aber. Wozu?
Ja? Und um deine Frage damit zu
beantworten, ja, es kommt einem sowohl lehrbuchhaft und in der
Theorie einem läuft das einem über den Weg als auch natürlich
im echten Projekt geschehen, weil die Benefits die daraus
resultieren sind ja zum Beispiel wie du meintest wettbewerbsfähig
bleiben, nicht an dem an der Marktentwicklung sage ich mal
vorbei zu entwickeln und natürlich auch Kosten effizient
zu sein, weil falsche Entwicklung kostet massiv viel
Geld. Und ich find es auch gut, dass
du es einfach genauso ansprichst, dass du sagst, es
kommt momentan einfach wieder aus allen Ecken, weil die
Marktlage ja auch gerade im deutschsprachigen Raum ja
angespannt ist. Genau, ist ja einfach so und da
spielt das natürlich ne große Rolle, dass man diese
Prinzipien, sag ich mal, natürlich wieder versucht.
Stark umzusetzen ja, also auf jeden Fall.
Das ist also die Vorteile, oder was ist da quasi, was eigentlich
damit gemeint ist? Ne, da wollen wir auch noch mal
ein bisschen genauer drauf eingehen, was ich ein bisschen
problematisch an der ganzen Geschichte finde ist, dass es
oft interpretiert wird, wenn man sagt, wir machen erst mal eine
80% Lösung, wird es oft interpretiert als.
Lass uns das erstmal Quick and dirty machen.
Ja, lass uns das erstmal machen, so nach dem Motto, Hauptsache es
läuft irgendwie ja sowas wie auch ja typische Dinge wie
Refactoring machen wir später, weil jetzt haben wir ja erstmal
80% ne und die 100% wären dann das Refactoring und das machen
wir später ne und? Ja.
Ich finde, das ist das. Es ist so n kleines Problem, was
wir auch heute noch mal genauer besprechen wollen, das ist ja
ein. Tatsächlich eine Verwechslung
ist, dass man das nicht gleichstellen kann, weil wenn du
Scope mit Qualität verwechselst, dann kann es halt zu einem
Problem führen, gerade auch in der Kommunikation und in der,
ich sag mal Erwartungshaltung, was zum Beispiel jetzt 80% sein
soll und was eben nicht, ne. Und wir können ja auch mal jetzt
gucken, dass wir sagen, OK, was ist jetzt der Unterschied
zwischen also ne Scope und Qualität, dass man das so n
bisschen absteckt, um halt auch wirklich noch mal n Feeling
dafür zu kriegen. OK, was ist denn eigentlich
wirklich der Kernpunkt, den wir also mit diesem 80% Ding
adressieren wollen, ne? Ja, ist eigentlich ne ganz gute
Unterscheidung, oder? Das ist eigentlich das was am
Ende zählt. Du hast das jetzt Scope genannt,
das find ich ganz gut. Zu sagen, wo reichen uns 80%
erstmal ne und wenn man das ganze jetzt zum Beispiel auf
Zeit mapt ja was ja auch so n Standard ist, aber halt leider
nicht immer ne gute. Ne gute Metrik ist, kann ich bei
beiden sowohl in der Softwarequalität als auch in
meinem Scope. Ich erklär gleich mal genau, was
ich jetzt zumindestens unter scope verstehe, wie du das
genannt hast. Kann man halt bei beiden mit
einer 80% Lösung Zeit einsparen. Das heißt es wirkt erstmal so
als wenn beides sag ich mal das gleiche Ziel verfolgt oder oder
ich mit beiden zum Ziel komme. Ja und Quick and Dirty ist halt
wirklich wie du es so schön genannt hast.
Genau der richtige Begriff eigentlich, weil es fühlt sich
erstmal gut an, es geht schnell ne, es funktioniert irgendwie
und man hat ja immer dieses Gefühl von ja, aber ich kann das
ja immer noch richtig machen, es geht ja erstmal nur darum zu
zeigen, dass es so läuft, dass es in die richtige Richtung
geht, ich Krieg ja n Feedback und wenn derjenige, der sich das
wünscht, sag ich mal, sagt ja genau so hab ich es mir
vorgestellt, dann kannst du da weitermachen und dann kann ich
das ja immer noch. Sag ich mal besser machen,
Hauptsache es läuft erstmal und ich kann es zeigen.
Ja auch so n klassisches ja wir refact dann das später ja haben
wir auch schon folgen zu gemacht.
Ja, le blancs law sag ich nur later equals never es wird halt
nicht passieren in der Regel das will man immer nicht hören, aber
ich mein jeder kann ja mal selbst drüber nachdenken wie es
bei einem selbst ist. Ja.
Wie lange leben to Do's in dem Quellcode?
Ja, gibt es welche, guckt gerne mal nach Liebe, zuhören, liebe
Zuhörer, auch wir beide, also ich weiß, wir haben locker
welche in irgendwelchen Projekten, die da einfach seit
Monaten drin leben, ja und die werden es wahrscheinlich nie
wieder raus schaffen, ja. Und das sind halt alles so
Anzeichen, dass man das denn wahrscheinlich eh nicht macht,
weil man ja dann an den nächsten Lösungen arbeitet.
Ne, vielleicht auch schon an den nächsten 20%, weil man sagt ja
ey, guck mal, das läuft doch und das kommt gut an, jetzt machen
wir weiter, aber ich bau dann halt auf sowas bröckling auf am
Ende und das ist halt gefährlich und trotzdem kann ich diesen
Zustand erstmal erreichen, indem ich zum Beispiel meine
Codequalität. Ja, meine Entwicklung sozusagen
schlechter durchführe, nenn ich es mal oder halt auch im Scope
Abstriche machen finde ich eher das richtige Wort.
Magst du aber mal erklären warum das n Unterschied ist, der super
essentiell ist am Ende, weil ich denke mal genau darauf möchtest
du ja hinaus, so wie du mich anguckst.
Ja, also genau NN inscope n Umfang würde ich halt sehen,
dass es halt beschreibt so was. Soll eigentlich also was soll
funktionell erreicht werden? Beispielsweise also wenn du
sagst du hast n Feature ne und dieses Feature soll eine
bestimmte Sache erfüllen, ja Stichwort zum Beispiel MVP, dann
willst du ja erstmal gucken, funktioniert das so oder
beziehungsweise ist das auch also du du du Erzeugst ein
Produkt mit einem MVP oder vielleicht nur n feature ne wenn
du sagst OK wir haben n Feature und dieses Feature kannst du
beliebig auf Dröseln. Du kannst es immer breiter
machen immer größer, du kannst immer noch mehr coole Dinge
kleine Gimmicks in dieses Feature einbauen, aber es ist
erstmal noch gar nicht notwendig und wie du auch meintest wenn
jetzt jemand kommt und sagt OK ist ja n cooles Feature aber das
brauchen wir gar nicht, völliger Quatsch, dann hast du natürlich
super viel Zeit investiert in einen Scope.
Für 100% deines Scopes sozusagen, um am Ende zu merken,
OK, das Feedback, was wir jetzt kriegen, am Ende ist irgendwie
blöd, ne und gerade wenn du jetzt relativ schnell es
hinkriegst irgendwie ne gewisse Lösung zu schaffen n gewissen
Scope aufzusetzen für n bestimmtes Feature
beispielsweise, dann kannst du ja relativ schnell checken, OK
wie. Was?
Krieg ich denn zurück? Ne, Wir hatten auch schon mal ne
Folge gemacht über das Pareto Prinzip heißt das glaub ich
dass. Du für 80% ne, also das ist ja
dieses 8020 Prinzip und wenn du für das ja spielt ja genau hier
rein. Wenn du für 80% 20% der Zeit
brauchst und umgekehrt, dann kriegst du natürlich relativ
schnell in einer kürzeren Zeit sag ich jetzt mal erstmal NNN
feature, was sich erstmal anfühlt wie n Feature wo man
gucken kann in welche Richtung das geht ne so das ist der Scope
ja aber die Qualität auf der anderen Seite ist natürlich was
ganz anderes. Ja also wenn du sagst du.
Willst einen Scope erfüllen mit 80%, dann geht es zum Beispiel
darum, dass du, wie ich meinte, ein Feature bis zu einem
bestimmten Punkt bringst. Und dieses Feature ist aber noch
nicht ganz fertig, aber du kannst erst mal schon mal
Feedback einholen, so wenn du die Qualität aber Anguckst, zum
Beispiel vom Code oder so, dann ist ja die Frage OK, heißt 80%
Lösung auch 80% Qualität, weil zum Beispiel sowas wie.
Ist der Code verständlich? Ist ja nur zu 80% verständlich,
sind vielleicht nur keine Ahnung 80% sagen wir mal abgetestet
also es ist vielleicht auch sehr ja Code coverage mit Test.
Lass uns mal nicht drüber reden, ja ist jetzt nicht die beste
Metrik, aber. Auch ob Architektur tragfähig
ist, ne oder ob es nicht irgendwie so irgendwelche blöden
Workarounds gibt, die man mal so rein mogelt.
Ne, und das ist halt genau der Unterschied, weil nur weil du
80% deines Scopes liefern willst, bedeutet das ja noch
lange nicht, dass du diese 80% des Features was du lieferst
oder was du zeigen möchtest, auch nur mit 80% der Qualität
bringst. Du kannst ja genauso, und das
sollte man auch an der Stelle ne der Qualitätsstelle auch
wirklich an die 100% gehen und sagen, das ist dein Feature.
Es ist noch nicht ganz fertig, es ist aber schon mal soweit,
dass man es quasi fühlen kann. Aber es ist auf jeden Fall mit
einer hohen Qualität gebaut. Ne ne und?
Da ist halt auch der Trade auf, der öfter mal in die falsche
Richtung kippt. Und ich glaub bei jedem ne, also
da würde ich mich jetzt auch nicht rausnehmen, das ist halt
immer sehr verlockend, sag ich mal.
Denn doch vielleicht den Scope n bisschen hoch zu drehen.
Und da führt die Qualität runter.
Ne, dass du sagst man kommt halt so ne Art Versuchung zu sagen na
ja, wir brauchen auf jeden Fall irgendwann noch bei dem Feature
noch ne weitere Funktion, da weiß ich eigentlich, dass das
kommt und dann ist man geneigt es schon direkt mit einzubauen
und dann denkt man sich so na ja, aber es muss auch irgendwie
fertig werden. Ja gut was mach ich jetzt ne und
dann hab ich halt mehrere Möglichkeiten und das ist halt
genau dieser Trade off ne wie du zum Beispiel meintest.
Tests ja, wartbarkeit. Ich kann natürlich auch sagen,
Ach weißt du, ich teste einfach später und dafür baue ich diese
Funktion jetzt schon mit ein. Dann habe ich quasi bisschen
mehr als ne 80% Lösung irgendwie schon geschafft vom Scope her
ne. Also ich hab halt schon
irgendwie mehr drin oder vielleicht hatte ich das so auch
als 80% definiert, das ist ja wirklich ne definitionssache, da
können wir später mal drüber reden.
Wie man das schneidet, was für 180% sind am Ende ja, aber Fakt
ist, dass ich an dem Punkt definitiv die Softwarequalität
auf mindestens 80%, wenn ich sogar wesentlich mehr runter
gedreht hab, weil ich es einfach nicht mehr abteste ja, weil ich
sage, ich mach das später und das ist ne Sache, was mir in
sehr vielen Projekten schon über den Weg gelaufen ist.
Diese Einstellung und es gibt ja auch so Sätze wie.
Software, die nicht getestet ist, wird definitiv fayen oder
ist definitiv falsch. Ich find das ist ne gute
Herangehensweise, weil es wird irgendwann dieser case.com, den
du nicht berücksichtigt hast. Dann der kann ja auch mit einer
höheren Wahrscheinlichkeit noch kommen, selbst wenn ich abteste,
aber dann hab ich schon mal ne Testumgebung.
Ich kann diesen Test Case nachziehen, ich kann zeigen guck
mal es funktioniert wirklich nicht implementier das oder
refector und dann ist ja grün der Test.
Ja das ist ne viel geilere practice um danach auch.
Zuversichtlich zu sein, dass es jetzt funktioniert, ne, weil ich
halt einfach diese ganze Umgebung schon hab und das ist
halt genau die Frage, wie schifft dich das hin und her
weil Fakt ist die letzten 20% sind unfassbar teuer.
Ne du hast ja das Pareto Prinzip genannt und ich find das kann
man an kleinen Beispielen gut erklären ja also ich kann zum
Beispiel nehmen wir mal ne Website ja also gerade alles was
so UIUX auch ist. Ne Login Screen zu machen, der
erstmal irgendwie beinhaltet was er so beinhalten muss, das geht
super schnell. Den am Ende aber vielleicht
wirklich gut aussehen zu lassen, vielleicht in so n Corporal
Design zu integrieren, ne, also dass das alles stimmig ist.
Ja, dass du vielleicht noch so n paar Gimmicks einbaust, weil
dein Unternehmen einfach dafür steht, ja.
Solche Geschichten oder unter der Haube, ja wie wird dieser,
wenn du jetzt zum Beispiel auf Backend Seite bist, wie wird
dieser Login request behandelt? Ja hab ich n vernünftiges
Errorhandling wie sehen die Rückgabe aus?
Also antworte ich auch vernünftig da drauf.
Wie sieht überhaupt meine Autorisierung oder ja dahinter
aus mein ganzer Ausprocess sind ja alles so Sachen, da hab ich
mehrere Möglichkeiten entweder ich hab n kleineren scope
erstmal ich find da kann man das auch gut dran erklären.
Kleinerer Scope zum Beispiel Anmeldung, E Mail und Passwort
ist jetzt mein Scope, das ist meine 80% Lösung, die anderen
20%, dass ich mich keine Ahnung mit Google Account noch anmelden
kann whatever das sind für mich dann so 20% wichtig ist, dass
ich in dieser 80% Lösung sicherstellen kann, dass man
sich in meinen Service anmelden kann mit dem User, der bei mir
hinterlegt ist beispielsweise. Ja genau, also du willst ja im
Endeffekt zum Beispiel eine saubere Validierung auch haben.
Du willst gucken, kannst du denn zum Beispiel wirklich hast?
Also hast du eine richtige Mail eingegeben oder kannst du dich
zum Beispiel auch mit einer falschen Mail, wenn du die
eigentlich gar nicht eine valide Mail ist, zum Beispiel anmelden
hast? Du zum Beispiel wirklich, was
übrigens nicht Triviales ist Google.
Ja n reg ex für e Mail googlen, das ist oder oder was auch
immer. Mit der 1 wird aber immer wieder
erstaunlich. Ich kenn das noch von früher,
das war aber so geil, ja wir brauchen den Reg ex für e Mail
ja guck mal ich hab den Na der funktioniert aber nicht richtig
und sowieso die Tatsache, dass e Mails sehr sehr komisch sein
dürfen ja hilft da auch nicht unbedingt, aber es ist ja was
ich eigentlich sagen will, es ist diese diese e Mail
Validierung ne kannst du das machen?
Ist das in Ordnung, kriegst du klare Fehler angezeigt, ne die
dir dann auch vielleicht wirklich helfen ist deine Logik
getestet was wir auch schon meinten oder ist der Code auch
verständlich? Ne das ist halt wichtig dann
auch wirklich für dieses MVP weil oft ist es ja dann auch
vielleicht so gerade wenn du wenn du diese dieses ich sag mal
die dieses Missverständnis hast und dir denkst.
Ja, es ist ja nur NMVP, also kann ich jetzt zum Beispiel
sagen, ich Hack es mal schnell zusammen, Validierung brauchen
wir noch nicht, errorhandling ist sowieso ja komm, das machen
wir später und logging, das ist ja dann hinterher auch
eigentlich nur noch wichtig, zum Beispiel wenn wenn es dann
soweit ist, weil momentan ist das ja auch alles noch erstmal
noch gar nicht so wichtig, das ist dann halt n Problem, wenn
man dann denkt, OK, nur NMVP wenn man.
Wenn man dann wieder denkt, OK, jetzt ist die Qualität gemeint,
ne, aber eigentlich geht es ja darum wie du meintest zu sagen
NMVP für du musst dich anmelden können ohne Schnickschnack, aber
es muss richtig funktionieren, ne ist auf jeden Fall NN
wichtiger Punkt und ich weiß ja auch, weil du vorhin auch MVP
meintest. Ich.
Mein man kommt so schnell in diesen Punkt.
Ja, dass du dir denkst, ich bau mal NMVP.
Und dann kommt noch n Feature drauf und noch n Feature und
noch n Feature. Du kommst ja relativ schnell da
raus, aber darf man nicht in diesen Trugschluss geraten, dass
man sich denkt, ja OK, also MBP wirklich wenig ja, also wirklich
nur so, dass es gerade funktioniert, ja OK, funktionell
aber nicht von der quasi Qualität dahinter, die
funktionell funktioniert ne klingt komisch funktionell.
Funktionell funktioniert find ich gut.
Ja, aber genau das ist der Punkt, da diesen das klar zu
unterscheiden sag ich mal ne, also wir haben ja jetzt gesagt,
so Pareto Prinzip, die letzten 20% kosten 80% Aufwand, das sagt
es ja aus und das gilt übrigens für sämtliche Sachen ja ist ja
nicht nur in der Softwareentwicklung so ist es
halt echt erstaunlich, dass es doch immer wieder greift.
Und ich finde, nehmen wir zum Beispiel Jakni, hatten wir ja
auch schon gesagt, ne, also You Ain't Gonna need it ist ja auch
n cooles Softwareprinzip oder Entwicklungsprinzip, dass du
sagst oder dich immer wieder fragst, brauche ich das jetzt
schon für das, was ich implementieren möchte, muss,
soll, wie auch immer, und da ist ja auch die Frage jakni sagt
doch nicht aus, ich mein, kann sich auch jeder mal wieder
selbst die Frage stellen. Oder ich formulier es mal
wirklich richtig als Frage, sagt Jagni aus.
OK, wir brauchen jetzt diesen kompletten Funktionsumfang, aber
du brauchst jetzt noch keine Tests und noch keine saubere
Architektur, weil das können wir nachziehen, wenn es einmal läuft
oder sagt Jagni du brauchst vielleicht wirklich erstmal nur
den E Mail Login mit Passwort und noch nicht die Google
Authentifizierung, dafür aber bitte komplett robust und
abgetestet und wir können darauf aufbauen.
Und ich mein das erstens oder? Genau.
Weder noch, Nein. Aber ich finde, wenn man sich
das so mal vor Augen führt, dann zeigt es doch eigentlich schon
ganz klar, dass genau die Softwarequalität nicht der Punkt
ist, wo man auf 80% geht, sondern da immer die möglichst
100% anstreben sollte und eher im Scope kleiner schneidet, dass
ich sage, OK, mein Feature ist so, aber.
Bis wir das so wie es jetzt definiert ist, umgesetzt haben,
dauert das Monate vielleicht ne. Vielleicht sollten wir das mal
kleiner schneiden, ne den Scope mal anders betrachten um zu
sagen jetzt können wir kleine Teillösung basteln, die wirklich
gut entwickelt sind, die wiederverwendbar sind, also dass
man das nicht irgendwann einfach wegwirft, weil das ist ne ganz
oft ne Konsequenz zu sagen wir machen das später und merkt dann
das ist alles wirklich wirklich nicht gut mehr was hier ist.
Rebuild also. Wie oft werden denn auch
Projekte einfach komplett neu aufgesetzt, dass man sagt, wir
müssen das von vorne machen, ja, Pass auf das.
Passiert aber neu aufsetzen ist ja zum Beispiel auch.
Warum wird sowas gemacht? Ja, weil du zum Beispiel
Technical DAP drin hast oder so ne, also gerade wenn du wenn du
so ne Checkliste brauchst ne und dir denkst so OK haben wir jetzt
ne 80% Scope erreicht oder haben wir 80% Qualität erreicht, ja so
dann kannst du kann man sich halt einfach relativ schnell mal
so diese Checkliste durchgehen und sagen OK wart mal.
Hatten wir, haben wir gerade im Projekt ne Situation wo
Technical debt steigt oder relativ hoch ist.
Ja OK Moment weiter. Ich möchte n Feature erweitern
ne und von von meiner Software das muss ich irgendwie
erweitern, irgendwas damit machen ist aber echt schwierig.
OK haben wir wieder n Punkt hat man vielleicht irgendwie kommt
Frust im Team auf ne kennt man ja auch manchmal, dass man sich
so denkt so ja. Ne, brauchst ja nur mal mit
irgendeinem anderen Entwickler oder einer anderen Entwicklerin
zu sprechen. Spätestens bei der zweiten
Person gibt es n bisschen, also kommt es relativ schnell dazu,
dass sich beschwert wird, ja oder kann es irgendwie sein,
dass du am Anfang vielleicht n relativ starken Fortschritt
machst und irgendwann später flacht die Kurve extrem ab, wenn
das alles, wenn wenn man das alles mit ja beantworten kann,
so nach dem Motto Ja kenn ich alles, das sagt mir jetzt
richtig was, dann ist das genau die Checkliste wo man genau
nachgucken kann und sich denken kann.
Gut, wir haben hier nicht 80% Scope erreicht, also vielleicht
schon, aber viel mehr haben wir 80% Qualität erreicht.
Ja oder nicht mal also nicht mal der Nerv.
Ja, also das ist dann quasi da, da wurde definitiv etwas
verwechselt, das heißt man ist dann am Anfang irgendwie schnell
ja, aber halt eben nur am Anfang und nicht am Ende, das ist halt
nicht langfristig, ja, das ist oft bei Projekten so, dass man
am Anfang denkt, jetzt geht es los, ja alle.
Fliegen und und man hat auch so n richtig geiles Gefühl und
denkt ja es geht übelst schnell voran.
So ja gut, aber da kam dann irgendwann die Verwechslung
rein. Richtig.
Und ich mein so technische Schuld kennt auch jeder, dass
die aufgebaut wird. Es lässt sich super schwer
vermeiden, also wenn man da nicht sehr diszipliniert ist und
genau halt da sagt OK unsere Codequalität ist da jetzt.
So gesehen nicht verhandelbar und absolute Prio 1 und wir
müssen einfach unsere Standards halten.
An der Stelle ne um so nah wie möglich an die 100% für unser
Projekt zu kommen, dann schaffe ich es natürlich diese
technische Schuld klein zu halten, ne weil die baut sich ja
meistens genau durch mangelnde Codequalität auf.
Ne, dass ich sage zum Beispiel. Ganz ehrlich, ich weiß jetzt
schon, in 2 Wochen werde ich diesen Part hier nicht mehr
verstehen. Das heißt, ich müsste auf jeden
Fall in nächster Zeit das mal refactern so und bis du das
machst, verstehst du ihn schon nicht mehr.
Du hast keine Tests, dann passiert n Fehler und du weißt
gar nicht OK, warum ist das nicht drin, warum geht das
nicht, ja kannst nirgendwo nachgucken was überhaupt dein
Verhalten in der Software sein soll, hast du vielleicht auch
vergessen über die Zeit ne so spezielle Sachen, wir gehen ja
nicht davon aus, dass man nicht mehr weiß was die Software an
sich macht, aber wir reden ja auch davon, dass der Teufel
manchmal im Detail steckt und du dann wirklich dir denkst, ich
habe keine Ahnung, warum das hier gerade so ist.
Ja, also und verstehst es dann halt auch nicht mehr und dann
kommt halt dieser Frust was du meinst und man kann ja einfach
auch mal sich überlegen, was sind in unserem Team gute
Practices oder schlechte Practices, was was erwarten wir,
das ist ja auch irgendwo ne Art Erwartungshaltung, ne, also wie
können wir denn sagen, lass uns doch.
Dieses 8020 Prinzip so nutzen, dass wir 80% Scope haben oder
Funktionalität und dafür aber mit 100% Qualität, das muss ja
so das Optimum als als Ziel sein, was man erreichen möchte,
weil ich dann. Schnell Dinge liefern kann im
Sinne von ich kann Feedback dafür kriegen, ne ich kann es
erweitern, weil die Qualität bei nahezu 100% ich find 100% klingt
immer so abgehoben ne jeder weiß 100% ist utopisch, aber es muss
ja das Ziel sein zu sagen ich möchte es so gut ich kann
entwickeln, stets immer ja und aber ich find.
Es gut, dass du das Ziel sagst, ne, weil es ist ja, es ist ja
genauso, wenn du das Ziel von 80% hast.
Ja, und dann quasi. Aber diese Verwechslung hast und
sagst 80% wovon Qualität wir können das und das Weglassen,
dann hast du vielleicht so ein so ein Zielbild von 80% im Kopf,
wie gesagt, mit dieser Verwechslung kommst aber auch
nicht an die 80% ran, ne, also sag ich jetzt mal so ne, das ist
ja nun ein Zielbild wo du sagst OK lass mal versuchen dahin zu
kommen, das ist gut, dass du es sagst, es ist auf jeden Fall
noch mal. Sollte man da auf jeden Fall
unterscheiden bei 100% klar das utopisch, ja.
Genau. Und was sind jetzt so gute
Practices, die man da verfolgen kann, weil ich finde, man muss
sich ja irgendwie ne Art Framework schaffen, wie man das
Ganze auch halten kann, weil ich find es halt wirklich, es ist
immer das gleiche. Am Anfang denkst du dir ja easy
easy oh ist das gut oh Mann was ich hier mache fantastisch ja
aber du kommst je mehr es wird und je mehr Druck vielleicht
reinkommt zeitlicher Druck vor allem ne und dann noch mehr
Features und dann vielleicht die Software auch immer komplexer
wird. Umso mehr fällt dir das alles
irgendwann auf die Füße, wenn du dann nicht nach gewissen
Vorgaben, die du auch für dich selbst als Entwicklerin oder
Entwickler hast, ne, weil Fakt ist, man muss Verantwortung für
seine Software übernehmen und dann ist es auch die eigene
Verantwortung zu sagen, Nein, so nicht, das können wir so nicht
machen, das wird uns auf die Füße fallen, wir müssen jetzt
hier mal kurz auf die Bremse treten und mal wirklich für
unsere Qualität sorgen. Ja und so gute Practice ist halt
zum Beispiel ist es getestet, ja haben wir.
Drauf geachtet, dass wir unsere Architektur, die wir mal
entschieden haben, ja, und ich geh jetzt nicht davon aus, dass
wir mal die Architektur komplett überdenken müssen, sowas
passiert auch, ja. Auch.
Wichtig es dann zu tun und nicht zu ignorieren.
Aber gehen wir mal davon aus, wir haben ne gute
Architekturentscheidung halt ich sie auch ein, bin ich in den
Grenzen wie ich mir das selbst mal überlegt habe oder hab ich
hier rumgepfuscht sind meine Funktionen wirklich passend dazu
auch benahmung? Ja es ist klingt so trivial,
aber. Wie oft also wirklich mal Hand
aufs Herz, wie oft macht man sowas wie ich nenn es erst mal a
oder Test oder irgendwas du willst einfach mal kurz ne
Variable haben oder irgendwie mal n Ergebnis haben.
Du willst einfach mal irgendwas kurz printen wie auch immer
alles cool um das kurz mal zu testen aber lass doch bitte die
Variable dann nicht mit A im Code drin oder so ist jetzt n
krasses Beispiel aber benahmung ist halt auch ne manchmal ist es
dann auch b richtig. Und hab ich das zum Beispiel
einfach und verständlich in der passenden Struktur umgesetzt?
Das sind so Praktiken, die ich finde, die mir zum Beispiel
helfen, wenn ich mich darauf fokussiere, dass ich auch
wirklich in der Qualität bleibe, die ich anstrebe, und wie
gesagt, natürlich ist das auch alles irgendwo, ne, wie soll ich
sagen, ne subjektive Sache, was für mich gute Codequalität ist,
für den anderen vielleicht nicht ne ist ja auch immer so ne
stilistische Frage sag ich mal. Es gibt bei manchen Sachen
richtig oder falsch, bei manchen aber nicht.
Ja, bei manchen ist es Geschmacksfrage, bei den anderen
Sachen muss man einfach klar sagen, es gibt nicht einen Test
irgendwie für die Software, tut mir leid, dann ist das in meinen
Augen falsch. Ja ja, das ist irgendwie.
Keine Ahnung, workaround, ich bau mal eben einen Workaround
ein oder sowas sind auch Dinge wo man sich so denkt.
Ja, man kann es ja auch verstehen.
Es gibt Möglichkeiten, wo du dir denkst, ja versteh ich alles,
warum das gerade so so wichtig ist.
Aber und das muss man sich, warum sich?
Es gut anfühlt, in dem Moment, da.
Genau. Und es gibt ja immer Argumente
für irgendwas. Ja, aber gerade wenn du sagst,
ja OK, also du machst jetzt ne Workaround und was passiert
dann, das machen wir später, das fixen wir später, das wird nie
passieren so und das ist halt genau der Punkt, dass man sich
so denkt, so OK an der Stelle. Arbeitet man ja vielleicht nach
einer 80% scope Lösung, aber vor allem auch, und das ist halt
wichtig, auch an, ich sag mal limitiert man seine Qualität
auch schon mal auf maximal 80% ne.
Also das ist ja auch sozusagen dann der der der Gedankengang,
was auch diese Verwechslung für n Problem sein kann, dass du
halt wirklich so n irgendwo n Limit setzt und solche Dinge
halt auch als. Es ist OK, akzeptierst, weißt
du, weil du im Kopf hast? 80% ja, es ist OK, 80% ist OK
so. Nee, es ist nicht OK, weil genau
das halt auch sowieso halt gar nicht rein, also niemals wieder
rauskommt, ne und das ist ne ja ich find.
Dass diese, das machen wir später oder fixen wir später.
Mentalität ist halt auch wieder ne Auslegungssache, weil sie
kann gut angewandt werden oder halt falsch ne sowas wie.
Nehmen wir noch mal den Login. Ja Oh, jetzt müsste ich hier das
und das noch einbauen, damit wir das auch noch ermöglichen.
Ja uns zu authentifizieren, Nein, das machen wir später, ist
an der Stelle die richtige Mentalität, weil jetzt ist es
gerade noch nicht wichtig um unseren Service so abbilden zu
können. Ja, wenn du aber sagst, boah,
ich müsste hier jetzt hab ich zum dritten Mal schon diese
Funktion hier irgendwie aufgebaut und bin hier irgendwie
ziemlich am Copy pasten. Dann ist das, wir machen später
Mentalität an der Stelle falsch, weil dann geht es auf Lasten der
Codequalität. Das heißt, wenn da dieser
Gedanke kommt zu sagen, ah, hab ich jetzt gerade echt keinen
Bock drauf, boah, ich glaub ich mach das später.
Da denn lieber mal kurz n Kaffee holen und durchschnaufen und
sagen so ich mach das jetzt, weil das auf jeden Fall
langfristig gesehen dir wieder Zeit spart.
Also ich find es halt wirklich erstaunlich, dass sozusagen n
ähnlicher Gedanke, aber auf nen andere auf was anderes
fokussiert, mal richtig mal falsch, ist sozusagen ne ja.
Ja, das stimmt. Also, das ist, aber es ist
natürlich auch wieder im Endeffekt der Kontext dann
dahinter ne, weil das eine, so hab ich das zumindest auch n
bisschen verstanden, denn. Dein erstes Beispiel, was du
genannt hast, das zahlt ja mehr dann auf so ne Art Yakni ein
schon, dass man sagt, OK, das brauchen wir zurzeit nicht, was
aber gleichzeitig auch wieder in den Scope irgendwo mehr oder
weniger einzahlt und das andere ist halt wirklich wieder ne
Qualitätsproblem, ne was du dann theoretisch aufbauen kannst, was
dann halt wiederum zu einem Problem führen kann.
Also es kann dich halt schützen in dem Sinne, dass du sagst, ey
warte mal, es ist wirklich gerade nicht mein Scope, dann
schützt es dich ja irgendwie. Dieser dieser Gedanke aber in
Qualitätssicht ja schadet es dir am Ende.
Ja, ja gut, den Scope der Software an sich sollte man
natürlich irgendwie im Blick haben, also nicht der, aber wir
reden ja davon, dass du jetzt vielleicht n neues Feature
einbaust. Ja genau, genau genau nee, und
da ist es definitiv dann natürlich richtig, auch klare
Grenzen zu ziehen und zu sagen. Bis hierhin erstmal und nicht
weiter, weil wir halt eben gesagt haben, wir bauen zum
Beispiel NMVP, Wir bauen erstmal eine Lösung, mit der man
anfangen kann und die dann verbessern kann.
Und ich finde, daran ist auch wirklich nichts verwerflich zu
sagen, ja, wir machen erstmal etwas, was ne, du kannst ja
damit auch schnelle Feedbackschleifen einholen, das
ist ja klar, es ist ne tolle, wirklich ne tolle Geschichte,
nur halt eben diesen Shift, diesen.
Auf das falsche darf man dann halt eben nicht bringen, ne?
Genau, es ist halt. Ich finde man muss da einfach so
von der Mentalität her, wie man das Ganze angeht ist das so n
also man muss es halt in die richtige Richtung shiften weißt
du wie ich das mein? Also dieses dieses Mindset halt
quasi an der richtigen Stelle sozusagen anwenden, ne ja.
Ja, du sollst also so als Spruch vielleicht, dass man jetzt
nicht, man soll zwar nicht alles bauen, ne, also nicht die 100%
Lösung bauen, aber das was man baut muss richtig gebaut werden.
So ja also du, das trifft es wirklich gut.
Ja du kannst ja natürlich auch n Haus bauen, ja und sagen gut,
OK, darin hab ich erstmal alles was ich brauche, den
Wintergarten brauch ich noch nicht ja das ist n nice to have
ja alles cool. So den kannst du später auch
noch dran packen. Aber erstmal musst du natürlich
irgendwas haben, wo du pennen kannst, wo du kochen kannst, wo
du dein Geschäft verrichten kannst, weißt du.
Aber du willst natürlich trotzdem, auch wenn du das Haus
gebaut hast, willst du ja nicht ein Haus mit einem kaputten Dach
haben, ja oder irgendwo regnet es rein, irgendwo wird es nass
oder irgendwo fehlt der Boden. Ja, das willst du natürlich
nicht, sondern das was da ist, soll ja richtig sein, es soll
ne, das ist genau das ist, das soll richtig gebaut sein, aber
es muss noch nicht alles da sein.
Genau. Und ich finde, dass diese
Denkweise, und die ist bei weitem nicht trivial und zeigt
halt auch, ob ein Developer oder developerin sag ich mal,
wirklich schon mehr Erfahrung gesammelt hat und auch schon
viel gesehen hat. Ne, und halt wirklich es schafft
in diesem Scope und vor allem in der Qualität zu bleiben oder man
halt doch immer so n bisschen shiftet und mal n bisschen.
Ja, die Bounderies sozusagen. Ja, also überschreitet, dass du
sagst, OK, jetzt hab ich doch irgendwie an der Qualität
geschlampt, so, das hätte ich nicht machen sollen.
Ich mein, dass es n Lernprozess ist und es passiert auch immer
wieder. Wie gesagt, ich glaube einfach
nur mit steigender Erfahrung passiert es weniger, hoffentlich
ja ja, aber man muss natürlich auch sagen und ich finde, das
ist auch wichtig, dass wir es ansprechen bei allem.
Guten Absichten hinter diesen 8020 zum Beispiel ne und auch
warum man das Macht. Klar kommen jetzt Leute oder
gibt es Leute die sagen, wie soll ich das denn in meinem
Projekt machen, Leute, wie soll denn 180% scope aussehen, wenn
ich beispielsweise Security relevante Systeme hab, kritische
Infrastruktur also so wirklich Sachen.
Wo es keinen Kompromiss gibt und mit Kompromiss mein ich jetzt
vor allem wieder nicht die Codequalität, sondern sowas wie
wir liefern erstmal n Teil von diesem Feature und du gibst uns
mal n Feedback, wenn das überhaupt nicht so funktionieren
kann, nehmen wir das Beispiel mit so Authentifizierung wenn du
sagst na ja, ich saug mir was aus den Fingern, wir haben jetzt
so ne dreistufige Authentifizierung, so was übelst
krasses ja und du sagst na ja Stufe 1 hab ich schon mal Check
das mal und die denken sich so. Junge, das ist viel zu unsicher.
Wir brauchen alle sofort, also nicht sofort, aber wenn du was
lieferst, dann bitte mit allen 3 Stufen so, weil das wirklich
wichtig ist. Ja klar, es wird immer so ne
Fälle geben, man muss halt gucken bei diesem Scope an.
Augenscanner oder Iris Scanner also weil wir gerade beim Haus
waren, da hab ich mir jetzt ungefähr so vorgestellt, dass du
sagst, du möchtest ne neue Tür haben, die n bisschen sicherer
ist und jemand kommt und baut dir diese Tür ein und sagt aber
das Schloss. Das kommt in 3 Wochen.
Zum Beispiel? Ja ist n Gutes ist n gutes
Beispiel. Also du kannst sie halt noch
nicht schließen, aber sie wird sehr sicher werden.
Gib mal Respekt, also das ist natürlich n guter Punkt und auch
n sehr gutes ne sehr gute Analogie, weil ja man muss
gucken kann man den Scope so schneiden, aber immer wenn ich
an solche Produkt, Produkte oder Projekte denke.
Denk ich auch automatisch daran, dass die Qualität noch viel,
viel weniger verhandelbar ist. Ja, das stimmt.
Und man. Muss aber auch dazu sagen, weil
wir ja auch von MVP geredet haben.
Wenn du sagst du machst n minimal viable Product, dann ist
es halt wirklich zum Beispiel auch gerade bei diesem Security
Beispiel ne mit diesen 3 Stufen ist es halt eben so, dass das
Produkt. Ja, wenn man das jetzt ganz
klein fest halt eben diese 3 Stufen erfordert.
Ja, da sagst du ja nicht OK ne, wenn du zum Beispiel die Tür als
MVP nimmst, da sagst du ja nicht OK, ich bau ne Tür ein und das
Schloss kommt später, weil das Produkt, damit es mindestens
leben kann, also eine Tür die sicher ist halt ne sollte man
halt schon einfach auch abschließen können und OK, guter
Punkt. Ja, lass uns mal abschließend
noch so n bisschen Take Aways mitgeben, so praktische Regeln.
Also wir haben ja auch schon so gute Ansätze, schlechte Ansätze,
die man so im Team verfolgen kann.
Besprochen ist natürlich wie gesagt aus unserer Sicht ne,
also hier auch mal noch mal die Anmerkung, dass das natürlich
subjektiv ist. Ne und Codequalität für jeden
auch was anderes ist. Deswegen ist das auch ne Art
Teamentscheid. Ja ich finde aber es gibt so
praktische Regeln, die man schon.
Sehr oft etablieren kann und sollte.
Ich find zum Beispiel gut, dass du gesagt hast, OK, wir haben
nen Scope und die Frage ist, wie schneiden wir den um erstmal 80%
zu haben und trotzdem irgendwie n Feedback kriegen können und n
Mehrwert schaffen. Ja es geht ja auch oft darum
möchte ich impact haben mit dem was ich mache und das zahlt ja
dann ganz stark darauf ein, dass ich sage lass lieber gucken wie
wir die Features schneiden und nicht wie wir die Qualität auf.
Schneiden oder separieren? Ja lieber erstmal weniger
funktionsumfahren anstatt zu sagen, ich teste später.
Das wäre ja genau diese Möglichkeit, sage ich, nee, ich
mach die volle Funktion, Tests schreibe ich später oder ich
mach ne Teilfunktion, dafür ist es komplett sauber entwickelt.
Und dann immer lieber zugunsten der Splittung, sag ich mal von
den Features. Ja und nicht dieses.
Wir fixen das später, wir machen das später, das gucken wir uns
später noch mal an. Mentalität aufbauen wenn es
keinen direkten Plan dahinter gibt, ne, ist ja auch so n
Punkt, man kann ja auch nen Refactoring einplanen, heißt ja
nicht. Was ist das, was refactoring?
Dann gibt es so ne Alarmglocke an und dann alle refactor,
refactor, refactor und so ne ich mein du kannst n refactoring ja
auch einplanen, gerade wenn du so in agilen Routinen unterwegs
bist. Ja ja.
Wie gesagt, man darf es halt nur nicht verschlafen und nicht
verschlampen sag ich jetzt mal. Und ich find auch so, wenn du
Dinge tust, wo du dir so denkst. So ja fühlt sich n bisschen an
wie n Workaround fühlt sich n bisschen hacky an, fühlt sich
irgendwie n bisschen komisch an. Dann höre gerne auch auf dein
Bauchgefühl, weil es ist im neusten Fall halt auch genauso
wie es sich halt eben anfühlt ne und ich finde man muss halt auch
immer gucken, man hat ja so Dinge wie zum Beispiel 80%
Lösung ne also jetzt wie gesagt wichtig hier wieder scope ist
natürlich extra dem quasi geschuldet oder der Gedankengang
ist natürlich es soll schneller gehen, du sollst jetzt zum
Beispiel schneller etwas. Liefern können.
Du sollst schneller Feedback bekommen können und das ist
alles in Ordnung und natürlich dauert aber eine annähernd 100%
Lösung in der Implementierung länger als eine 80% oder 50%
Lösung auch in der Qualität, das ist klar, nur die Frage ist, wo
möchtest du diese Abstriche machen?
Ne und genau das ist hatte ich ja auch am Anfang oder in der
Mitte der Folge auch schon mal angesprochen.
Du kannst am Anfang relativ schnell hoch Rampen, auch wenn
du die Qualität schleifen lässt, bis zu einem bestimmten Punkt
und dann hast du aber n riesengroßes Problem.
Ab einem bestimmten Punkt, wo es einfach nicht mehr vorangeht und
dann kommen meistens, und das sind ganz, ganz viele Projekte
was man liest, hört, wo man auch schon selber dran gearbeitet
hat, vielleicht wo man sich dann denkt, komischerweise ist jetzt
n Punkt erreicht, wo auf einmal gar nicht mehr diese.
Diese Geschwindigkeit vorangeht, und das ist sehr, sehr oft
zurückzuführen darauf, dass man sich gesagt hat, ich sag jetzt
ganz bewusst, scheiß mal erstmal auf die Qualität ist erstmal
nicht so. Da hab ich auch mal zu dem
ganzen Thema n ganz coolen Satz gehört.
Der war so Code den du heute schreibst.
Wirst du morgen hassen, wenn du genau darauf sag ich mal.
Verzichtest oder nicht verzichtest, sondern da so n
bisschen nachlässig wirst. Ne und ich finde das ist n Satz,
den kann man sich vor Augen führen und wenn es denn mal
wieder zutrifft sich denken ha und eigentlich weiß ich genau
warum ich wieder an diesem Punkt gelandet bin.
Ja, das ist eigentlich so, ich glaub dann haben wir das ganz
cool abgehandelt ne also was ist so das Fazit, die 80%.
Heißen aus unserer Sicht weniger bauen, aber das, was gebaut
wird, sollte sich nach 100% Lösung anfühlen.
Wie gesagt, das ist n Ziel 100% man kann nicht sagen ich hab das
nach 100% gemacht, das sollte jedem klar sein, aber es sollte
immer das Ziel sein ne. Dass man sagen kann, ich bin ja,
ich sag mal, ich bin auch stolz darauf, was ich gebaut hab, das
fühlt sich gut an, das ist, das ist wirklich gut gecoded so, und
jetzt kann ich quasi den nächsten Raum machen in deiner
Hausanalogie oder den nächsten Stein drauf setzen, egal wie man
jetzt den Scope nimmt, ne ja. Nee, ich hab da gar nichts mehr
hinzu mehr hinzuzufügen. Deswegen sind wir eigentlich so
gut wie durch, oder? Hat Spaß zu quatschen dann.
Bleibt mir nur noch zu sagen, Liebe Zora, Liebe Zora, falls
dir die Folge gefallen hat oder du n Feedback hast oder auch
schon das ein oder andere Mal in diese Falle getappt bist und
vielleicht sogar richtig coole Lösungsansätze dafür hast, Teil
es gerne mit uns und der Community.
Meld dich bei uns, komm auf unseren Discord, schreib direkt
mit den anderen oder uns ne Nachricht auf der Plattform
deiner Wahl oder ne e Mail findest du auch in den
Shownotes. Ansonsten wie gesagt, lass gern
Follow da, falls noch nicht getan, das unterstützt uns
ungemein. Fabi hat auch den Spendenlink
erwähnt, also falls du darauf Bock hast und dir denkst, so
Mensch ja, euer Projekt ist geil, das möchte ich gerne
unterstützen, dann super super vielen vielen Dank dafür.
Empfehlen auch gerne weiter den Podcast, das hilft uns auch sehr
und ansonsten habt alle ne schöne Woche nächste Woche
Donnerstag 18:00 Uhr geht es weiter bis dahin ciao ciao deine
Coding Buns. Gemeinsam besser heißt das jetzt
auch, ich muss zum Mittagessen 89% kaufen.
Nicht hast du Dollar. Ich glaub du bist ein
Topfnascher. Also ich lecke mal die Schüssel
aus.