Zu einer Software, dann ist einfach ein liebenswürdiger Ausdruck für das S, der die größte Scheiße, also ein bisschen klingt, ein bisschen gemein. Aber Coding Buddy, Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Ein herzliches Hallo hier wieder zur neuen Folge vom Coding Buddies Podcast. Die Gastgeber sind natürlich wieder ich, der Fabi und der tolle Tino A. Tino Grüße dich Was geht ab? Wie geht es dir heute?
Wie geht es dir? Ja, gut, gut, gut, alles beim alten, alles wie immer, mir gehts gut, ich hab Bock, wir können loslegen und lass mal lass mal richtig starten jetzt. Wieder kalter, bisschen kalt, kalt, kalt. Draußen hat sich. Abgekühlt? Das stimmt aber. Geht bei dir. Sagst einfach drüber stehen. Einfach einfach Wegner.
Ich bin ich bin die Flamme. Nein, genau, wir wollen heute mal wieder über was sprechen und um das Thema mal so n bisschen einzuleiten, möchte ich, dass du dir mal was vorstellst und zwar stell dir mal vor, du OKN Umzug steht dann ne und du machst diesen Umzug, räumt die Sachen rein in deine neue Wohnung. Und kennst du diese, diese diese bau Lampen, die manchmal einfach so an der Decke baumeln? Ja, weißt du die über mir hängt?
OK, geil, nein, nein, ich weiß worauf du hinaus willst, aber erzähl mal weiter deine Story. So und du kommst rein. Zum Beispiel in den in den eingangs Flur und da ist halt so ne so ne Bau lampe ne und ja du räumst deine ganze Wohnung ein, du bringst Bilder an die Wand, du räumst deine Kartons. Aus. Das dauert vielleicht. 2 Wochen und du denkst die ganze Zeit diese diese Bau lampe. Die mach ich noch weg. Also da kommt ne richtige Lampe hin so. Und.
Das geht so ein 2 Wochen ein 2 Monate und du denkst immer noch diese Bauamt die wird auf jeden Fall, also die ersetzt sich noch, ich muss nur die richtige Lampe finden, so und irgendwann ziehst du wieder aus und die Bau Lampe war unverändert so, das heißt quasi. Und lässt sie natürlich für den Nachmieter. Natürlich war der Brauch neue. Die bleibt da also. Das Ding ist einfach so, worauf
ich hinaus will n bisschen ist. Kennst du diese Situation, weil ich kenne diese Situation mit solchen Bildern eigentlich schon ganz gut. Ich weiß nicht, ob dir das schon mal passiert ist, aber ich finde, das ist, wenn man jetzt im Umzugs Kontext ist, das so ein Klassiker. Das einfach unter Klassiker. Also einfach das einfach so. Lampe einfach bleibt. Ja, also im Flur hat dich ja glaube ich auch ewig lampe hängt, das war so ein bisschen.
Ich wollte dich jetzt. Verstört, dass es nicht auffällt, aber im Prinzip war es eigentlich nur eine Fassung. Was? Hast du da so so hier von so einem Geburtstags Kringel gedünstet, dran gemacht oder was? Wie nennt man Gedöns? Na Kriegel Gedöns ist der. Fachbegriff? Nee, da war ja noch ein Spiegel, und dann lag das so halbwegs obendrauf. Und am. Spiel. Gehört du? Warst sehr kreativ. Natürlich, aber ich akzeptiert habe, dass die da nicht verschwinden.
Wird der nicht der wichtigste Punkt der ganzen Sache ist? Ja, du brauchst Licht, du hast Licht, also du hast quasi irgendwie. Etwas, was funktioniert, aber was noch nicht so wirklich perfekt ist vielleicht, aber es funktioniert und damit kann man es ja theoretisch lassen. Genau, weil du kümmerst dich dann einfach später drum, um dann richtig richtig hübsch zu machen. Genau. Und jetzt fragen sich natürlich die Zuhörerinnen und Zuhörer, was hat das mit Softwareentwicklung? Zu tun.
Erzähl doch mal so jetzt, da möchte ich jetzt an dich abgeben. Was hat die ganze Geschichte das? Weiß ich auch nicht so wirklich, warum die Geschichte erzählt hast, aber ich komme einfach mal heutigen Thema. Nein, Quatsch. Natürlich hat es was mit dem. Absolut bekannten und ominösen
Le Blancs Lord zu tun. Was besagt Later equals never und im Prinzip das was du geschildert hast, lässt sich halt wunderbar auf die Softwareentwicklung übertragen, weil ich denke jeder der schon mal in größeren Projekten gearbeitet hat oder beziehungsweise in im Arbeitsumfeld wo es dann halt auch wirklich Meilensteine gibt und Deadlines die man einhalten muss, da tritt dann sehr schnell mal auf dieses Gesetz. Und zwar du bist dabei, deine
Features zu entwickeln. Du gibst dir Mühe, am Anfang ist alles cool, wie du meinst. Du ziehst quasi ein in deiner Entwicklungs Umgebung ne und fängt an die ersten Sachen zu machen, aber Umfang kommt Druck auf die ganze Nummer und du hast halt quasi nicht mehr die Zeit alles sorgfältig zu machen weil Sachen fertig werden müssen und dann kommt genau dieser Punkt, dass du sagst es funktioniert ja erstmal genauso wie die Bauland.
Ich habe ein Feature entwickelt, das funktioniert, aber eigentlich weiß ich schon, das kann so nicht bleiben. Es gibt vielleicht ein Fall, den ich noch nicht berücksichtigt.
Habe dann schöner. Wie es kann schöner werden, das ist auch ein Punkt, richtig, oder kommen wir nochmal zurück, dass du weißt halt so und es gibt einen super seltenen Fall, dass dann vielleicht ein Fehler auftritt, aber das ist sehr unwahrscheinlich und würdest du es dann halt erstmal so lassen und dich quasi später darum kümmern und diese Anführungszeichen, die ich gemacht hab, müsst ihr euch jetzt alle vorstellen später und genau das soll heute unser Thema
sein und ich würde mich freuen, wenn wir vielleicht einfach mal so von uns selbst berichten. Wie wir das quasi so erlebt haben, wie man am besten damit umgeht und wie man vielleicht auch versuchen kann, das zu vermeiden. So gute Fragestellung würde ich sagen oder dann leg mal los, ich geh mal. Ich hau mal ab hier. Du musst noch umziehen. Genau.
Nein, aber kennst du diese Situation oder würdest du sagen, ja OK, auf in der Theorie kannst du dir vorstellen, dass das Leuten passiert, aber ist es auch praxisbezogen? Also hast du diese Erfahrung wirklich schon gemacht? Ja, also definitiv. Es sind halt sind halt weiß ich nicht, das begegnet einem irgendwie an vielen Stellen
einfach, also auch regelmäßig. Ich glaube, das schönste Beispiel, dass so ein to do im Code, dass man sich rein schreibt, eventuell ne hat, vielleicht wahrscheinlich auch schon wieder erlebt to do das und das ne und. Was ist die Intention hinter einem to do? Warum schreibe ich das dahin? Ja, es ist ne gute Frage. Du willst es halt später noch mal machen, ne? Genau, also du willst es halt jetzt in dem Augenblick nicht machen, obwohl du weißt, dass was geändert werden muss.
Ja, genau. Und später ist gleich niemals. Also ne, also willst du später machen. Also man kennt. Also ich kenne das auf jeden Fall, dass man zum Beispiel und Code schreibt oder TO dos im Code findet und entweder halt dann heißt, also man selber sich denkt, ja ja ich mach das später noch gut, dass ich hingeschrieben hab, ich mach es später noch.
Was aber nicht passiert oder dass man halt irgendwie to findet, von wem anders und sich dann sag mal was ist das hier, ja wir müssen das und das noch machen, AOK manchmal gibt es so, geht sogar so weit, dass man to do findet und sagt, was ist denn das A. Ja ja, aber das ist nicht mehr, ist nicht mehr notwendig. Also oder weiß gar nicht mehr,
was man da machen wollte. Auch ein gutes Beispiel, auch ein gutes Beispiel also, das ist so finde ich das so, eines der ersten Anzeichen von so einem Later. Equals never von so einem. Es ist so ein to do meiner Meinung nach ne, aber es gibt ja auch noch andere Dinge. Beispiel to S finde ich auch absolut furchtbar. Und schreib sie trotzdem selbst. Also das ist halt genau das Ding. Es ist ja jetzt nicht einfach so. Ja, das sollte man niemals tun und dann macht man es auch nicht.
Jeder kommt glaube ich mal in diesem Moment oder in diese Situation, dass man sagt, ach, verdammt noch mal, ich mach jetzt einfach n to daran, ich, ich kann das jetzt nicht machen, ich muss jetzt erst mal was anderes fertig machen und das ist halt genau die Falle dahinter, dass man quasi das Gesetz erfüllt und sagt, OK, ich werde niemals machen, innerlich
weiß man, wird es niemals sagen. Ja, man muss natürlich auch ein bisschen sagen, dass natürlich dieses, dieses Later, es never das ist eine Tendenz, ne, also nur weil man jetzt zum Beispiel sagt, so OK, man schreibt jetzt n to do dran oder so heißt das ja nicht zu hundertprozentiger Wahrscheinlichkeit, OK, das wird niemals passieren. Ja, natürlich nicht. Aber es geht um das Zeichen dafür, dass man genau in diese
Richtung läuft. Halt ne genau und ich kenne das Halt von mir selbst auch, dass du den Darm an to do anschreibst und dann also jetzt nicht die ganze Zeit, aber wenn die anderen nicht. Abgearbeitet werden. Dann hast du halt doch irgendwann eine Liste, die relativ lang ist, ne? Ich muss jetzt ein Feature implementieren to do feature 1 implementieren gut, dann zweite nächstes. Mann, war das ein stressiger Tag. Leider.
Aber das Thema ist genau was du meintest mit Features und Feature. 2. Wenn du sagst OK ich habe jetzt das erste Feature beendet und implementiert und hab dann noch eigentlich offene Punkte, heißt es ja nicht, dass dann erstmal keinen zweiter Request kommt, ein anderes Feature zu implementieren, also die Arbeit bleibt ja nicht aus, so dass du dann 100% deiner Zeit in die TO dos stecken kannst.
Im Gegenteil, es werden in der Realität meistens mehr to dos und du musst trotzdem weiter quasi vorwärts entwickeln und nicht zurückschauen. Und das ist ja auch genau das Thema Refactoring, was wir schon besprochen hatten.
Super Beispiel definitiv. Na Refactoring ist so eine unfassbar wichtige Sache um auch gerade sone Sachen aufzuräumen und zu verbessern und die Code Basis sauber zu halten ne und ob sag ich mal nahezu optimal zu halten weil ich meine was optimal ne aber halt nah dran zu kommen und wenn du jetzt viel mit to dos arbeitest schiebst du das alles auf und das heißt du Reflectors dann wahrscheinlich auch nicht und es wird halt immer schlimmer. Definitiv.
Steigt ja auch die Wahrscheinlichkeit nicht, steigt sie, sinkt die Wahrscheinlichkeit, dass du es irgendwann doch mal machst. Und dann sind wir wieder bei dem Ding, ne. Weil es halt einfach zu viele werden irgendwann. Genau. Ja, also gerade bei bei bei Refactoring ist es natürlich, hatten wir wie gesagt schon mal drüber gesprochen. Das ich glaube, dass ist halt wichtig, dass man gerade bei Refactoring ne, wenn man irgendwie entdeckt, so OK, da könnte man jetzt was verbessern dann.
Finde ich gibt es 2 verschiedene Möglichkeiten. Entweder man macht es wirklich sofort oder man schließt die aktuelle Aufgabe ab und wirklich im Anschluss macht man das dann, weil manchmal ist es natürlich schwierig so ein gewisser Art von von sägezahn Effekt, dass man immer wieder rausgerissen wird, sag ich mal aus der eigentlichen Aufgabe. Also angenommen du hast jetzt irgendwie ne bestimmte Aufgabe, die du umsetzen möchtest und siehst dann o hier könnte ich
noch wach, dann mach ich das. So war ich nicht gerade a. Ja ja, genau, und dann merkst du wieder, jetzt kann ich hier was scheiße war ich gerade, also man muss da halt natürlich auch ein bisschen gucken, dass nicht völlig übertreibt, aber halt strukturiert macht ne. Ja, also das Aufschieben bedeutet in dem Fall ja nicht, mach sofort, sonst niemals ne.
Also das heißt das ja auch nicht, sondern aufschieben im Sinne von ich schiebe es halt wirklich Tage hinaus oder kümmer mich dann schon um ganz andere Themen. Ich bin da ganz bei dir. Wenn ich jetzt gerade in der Feature Implementierung bin und mir fallen Sachen auf, kann ich ja signos machen und wenn das Feature erst mal grundlegend funktioniert, kann ich mich darum kümmern, gerade damit man gedanklich nicht immer rausgerissen wird, da bin ich
absolut bei dir. Problematisch wird es halt, wenn du sagst, dass Features abgeschlossen und der das offene liegt auf der to do Liste und ich fang was neues an, weil dann läufst du halt genau in die Richtung ne, also in die falsche wohlgemerkt. Aber das ist noch mal, was ich nochmal interessant finde, weil ich ja gerade so meinte to do feature 1 so nächstes was sind denn so eigentlich oftmals TO dos die so anfallen? Also das das geht ja hier wahrscheinlich nicht um riesengroße.
Punkte, oder also? Nee, also klassisches Refactoring, dass du sagst, OK, pass auf, ich könnte halt die Klasse zum Beispiel in 2 aufteilen, die einfach zu groß geworden, beispielsweise Schnittstellen vielleicht optimieren, dass sich die mittlerweile halt gar nicht mehr so wirklich richtig anfühlen oder dass die Software sich so weiterentwickelt hat, dass sie eigentlich gar nicht mehr
passen. Ja, auch ein Klassiker ist fehlender Test. Abdeckung über Tests haben wir auch gesprochen, dass man einfach sagt, Na ja, die Test schreibe ich noch dafür. Also das ist ein Thema, da werde ich wirklich emotional, weil das hab ich schon sehr oft gehört in meinem Arbeitsleben, und meistens kommen diese Tests nicht mehr. Ja. Also da greift dieses Gesetz extrem, finde ich.
Also wenn ich sage, OK, ich werde später die Tests schreiben für dieses Feature und ich sag erstmals funktioniert, weil ich habs einmal per Hand getestet, das also das ist, das ist wirklich ein heikles Thema, weil dann hast du noch ne und ne und dann auf einmal nachher 300 400 Tests aufwärts, keine Ahnung.
Das ist, da kommt man ja schnell hin, ne, ja klar, dann solltest du dich hinsetzen und nochmal jedes Feature überlegen und die Tests dafür schreiben, das macht keiner mehr oder du hast einen riesen Overhead am Ende, weil also wesentlich mehr Zeit verbraucht als sie direkt zu schreiben. Ja, auf jeden Fall. Gerade wenn du dir überlegst, dass wenn wenn wenn du im Nachhinein Test und das nicht zumindest wirklich an der Entwicklung machst.
Also wir gehen jetzt nicht unbedingt immer davon aus, dass muss jetzt nicht immer alles TDD sein. Also Test driven development. Aber nichtsdestotrotz meint das meine. Ich aber nicht. Aber nichtsdestotrotz, wenn du so stark nachgelagert deine deine deine Tests schreibst, ne, weil du das einfach immer nach hinten schiebst, dann ist die Wahrscheinlichkeit sehr groß, dass du quasi deine Implementierung Test und nicht die Anforderungen selber und dann wird es halt unter
Umständen auch schwierig. Mal ganz davon ab, dass du im Endeffekt sagst, OK, wir haben gerade von Refactoring gesprochen, was man vielleicht aufschiebt, angenommen du machst das Refactoring, hast aber vielleicht fehlende Tests, das heißt die Ganze. Dein, dein dein Vertrauen in deinen Refactoring singt vielleicht, weil du gar nicht weißt. OK, ist das. Jetzt hat es jetzt funktioniert, verhält sich meine Software noch
so wie vorher. Also das ist ein riesen Ratten Schwanz der sich da mitzieht und deswegen ist es glaube ich einfach wichtig. An der Stelle auch konsequent Sachen eben nicht aufzuschieben. Ne. Ja, absolut. Hattest du so eine Situation, mein Projekt mit dem Test aufschieben. Also ich meine du, ihr hattet ja nach TD gearbeitet, aber habt ihr selbst da erlebt, dass sie in diese Situation gekommen
seid? Also bei Tests, bei Tests schreiben war es jetzt eigentlich nicht so, eher so, dass man irgendwie gemerkt hat, OK, hier fehlt irgendwie noch ne, haben wir noch n vergessen, dann wird halt erstmal der Test geschrieben und dann. Sozusagen dieser Fall also n roter Test erzeugt, dass man wirklich merkt mit diesem Test.
OK, hier der Test fehlt und das heißt die Software kann diese Anforderungen, die ich gerade versucht habe Abzutasten, nicht erfüllen und dann kann man sich sozusagen an die an die Implementierung für diesen Test sozusagen, dass der Test grün wird dran setzen. Also das war aber jetzt eigentlich wirklich, also hab ich nicht so erlebt, dass da Tests ausgeblieben sind. Oder auch mit Absicht geschoben
worden. Meine ich jetzt ne was ich gemerkt habe ist, dass zum Beispiel manchmal Momente auftreten, wo man vielleicht irgendwie, also man hat ja ne gewisse User Story oder ein Task den abarbeitet, wo Anforderungen im Normalfall oder sollten sie drin stehen, ne, also wie soll also was sind die Anforderungen an dieses neue Feature zum Beispiel? Und wenn du dann zum Beispiel merkst, a guck mal hier, was weiß ich, du hast vielleicht.
Eine gewisse Fehler Behandlung und merkst OK, wir haben jetzt hier vielleicht noch eine Möglichkeit die eintreten könnte, die ist jetzt aber erstmal so in den Anforderungen nicht abgedeckt, ist auch sehr unwahrscheinlich, dass sie eintritt, aber ich schreib mal to do oder hab meine eigene Liste wo ich mit drauf schreibe, das müsste man noch mal machen ne. Weil ich das irgendwie gemerkt
hab. Das ist natürlich dann also sowas ist auf jeden Fall vorgekommen, dass man dann irgendwie sowas schon mal geschoben hat. Und im Endeffekt dann auch sowas halt erstmal nicht gemacht wurde. Ne, also teilweise sogar schon so dass dann dieser Fehler auch wirklich. Von Usern entdeckt wurde also beziehungsweise was heißt entdeckt, also der dem User ist das passiert und wir haben das dann über unser Monitoring mitbekommen.
Na OK, na immerhin. Ja, aber also Sondersituation kenne ich auch aus dem Klassiker ist angenommen Du entwickelst eine Software und arbeitest selbst halt auch damit ne, also du bist halt auch selbst Anwender sag ich mal. Oder ein Teil der Anwender. Und merkst halt eigentlich.
Aber das ist schön Wound, das ist also ist eigentlich nicht, man könnte das Geiler implementieren und statt zu sagen, ich änder das ab und Reflector den Code nochmal und mach das, also änder das ganze Feature noch mal ab, fängt man an diesen Workaround zu nutzen, zu verinnerlichen und er regt sich gefühlt jedes Mal, auch wenn du an diesem Punkt kommst, dass es eigentlich total unhandlich ist.
Aber das ist einfach, es ist dann einfach so und das hatte ich damals auch ganz viel, wo ich mir so denke, ey, warum nicht einmal jetzt sage OK, wir nehmen uns die Zeit ändern. Das und danach fühlt sich die Software vom Handling, also ja von diesem ganzen UX sag ich mal von der Experience dahinter viel besser an. Ja, das finde ich auch richtig, klassisches Beispiel dahinter, aber wie ist es natürlich so ist
bis heute ist. Nicht geändert, aber das ist, das ist auch finde ich NN sehr, sehr spannender Punkt, und zwar Workarounds. Bei Workarounds feilen meiner Meinung nach zwar unter dieses OK, wir haben einen Workaround drin in unserem Code und wir müssen ihn mal. Ausbau in diesen Workaround wieder, und das passiert dann nicht ne Never, aber was finde ich noch einen Punkt dazu top ist ist wieso kommt es dann dazu, dass dieser Workaround einmal überhaupt initial eingesetzt oder erstellt wurde?
Weißt du und da kenn ich auf jeden Fall auch, also da hab ich glaube ich meiner softwareentwicklungs Karriere schon so viele Diskussionen in in. Landings und so weiter geführt, wo über bestimmte Features geredet wurde und dies wollen wir nicht. Vielleicht erstmal das so und so machen so und dann merkst du, OK Moment, es geht hier darum einen Workaround zu implementieren, damit das erste Mal funktioniert und da habe ich schon so viele Diskussionen geführt, miterlebt wie auch immer.
Wo es halt wirklich darum ging zu sagen, Nein, wir werden jetzt, also dann lass uns wenigstens eine Lösung überlegen, die sag ich jetzt mal zukunftsträchtig ist und erweiterbar ist dahingehend, was wirklich sein soll, auch wenn es jetzt ein bisschen länger dauert, aber wichtig ist, dass wir keinen Workaround einbauen, weil, und das war halt auch immer so das Ding, und das ist halt.
Viele Entwickler und Entwicklerinnen stimmen da eigentlich auch immer zu, dass man sagt, wir können keinen Workaround einbauen, weil wenn du einen so einen Workaround eingebaut hast, dann kriegst du nie wieder raus.
Zumindestens sehr schwer und genau, aber das merkst du ja schon an der Wortwahl. Ne, dass das erstmal funktioniert und wenn dann quasi das Feature oder im Prinzip in dem Fall ein Hotfix eigentlich nur so, wie sich das jetzt anhört, Beispiel quasi schon Ablaufdatum hat, wenn du eigentlich weißt, das kann so nicht bleiben, aber wie du meinst wenn es drin ist ist es drin und dann wird es auch schwer das zu ändern, weil dann kommen wieder andere super
wichtige Themen und das ist ja genau in diesem Modus in dem man immer mehr verfällt und ich das kennt einfach jeder. Entwickler, du musst immer weiter, weiter, weiter, weiter.
Neues Feature. Oh Gott, wir müssen fertig werden, wir haben keine Ahnung welche Meilensteine die wir erreichen müssen, irgendwelche Releases, wir haben deadlines ne und du fängst dann an immer weiter und weiter zu implementieren und guckst halt irgendwann nicht mehr zurück und im Prinzip redet man sich ja selbst schön, es ist ja quasi ein Schönreden zu sagen, ja ich mach jetzt ein to do ran, weil dann mach ich später also du schreibst dir quasi einen
eigenen Entschuldigungs Zettel. Hat den Kopf, dass du dich da noch drum kümmern wirst, weil du weißt, dass es falsch ist. Du weißt einfach, dass es falsch ist, jetzt nichts zu tun. Vor allem also. Oder wie siehst du das? Ja, aber definitiv. Was weiß ich zum Beispiel auch nochmal wissen will, wie es dir dabei geht ist, wie nimmst du denn solche To dos wahr, wenn sie im Code stehen? Von meiner eigenen. Egal, irgendwelche.
To do Scrollst über den Code und siehst n to do was geht dir durch den Kopf, was ist also, wie reagierst du darauf? Ja, das ist nämlich ein guter Punkt, weil du liest das. Also wenn du es überhaupt liest, wenn du nur so rüber Scrolls, glaube ich, dann ist es halt schon wieder Geschichte, quasi in dem Moment, wenn du drüber bist. Aber wenn du es dir wirklich nochmal durchliest, kommst du ja auch nicht zu dem Punkt zu sagen ohne Umlage.
Jetzt ist aber wirklich Zeit das zu machen, sondern ach ja, wie du vorhin meintest ach ja, stimmt, was wollen wir noch machen, ja ja nee, das müssen wir wirklich tun und dann bist du trotzdem in einem anderen Thema, weil du einfach schon zu weit weg bist von diesem Punkt. Aber was ich auch gut finde, weil du meintest, wenn man die überhaupt anguckt, weil das ist
nämlich. Das erste wie ich, also wie ich das bei mir mit kriege, wenn ich irgendwo die, also wenn du zum Beispiel in bestimmten IDN to do hinschreibst du doppelpunkt, dann wird das sogar highlighted. In Gelb zum Beispiel. Und wenn ich sowas sehe, dann ignoriere ich das.
Also ich ich seh s erst mal gar nicht, außer ich will es wirklich aktiv wahrnehmen und wenn ich dann wirklich aktiv wahrnehme und mir sagen OK les ich mir mal durch und dann kriege ich schlechte Laune. Und die wollen wir nicht und deswegen ignorieren. Was aber das ist doch, weißt du, also das ist halt da, denk ich mir so, dass das Scheiße, also wieso will man denn irgendwas in Code einbauen, wenn man sich so
denkt? Oh nee, also was eigentlich schon von vornherein entweder man ignoriert oder man denkt sich, boah nee, weißt du auch kein Bock, also weißt du, das sind ja Sachen die einfach irgendwie. Eigentlich vermeidbar sind. Weißt du genau, wenn du sagst, OK, ich kümmere mich da drum, ich lasse das jetzt mal mit diesen to dos beziehungsweise ich mache meine Aufgabe fertig und danach gehe ich das an, lasse gar nicht erst aufkommen, dann haste ja im Endeffekt schon mal.
Ja, schöner weißt. Du was dann? Ja, dann geht es auf jeden Fall in die richtige Richtung, ist auf jeden Fall ein Ansatz, um darin besser zu werden, auf jeden Fall. Wie gesagt, früher habe ich auf jeden Fall mehr to dos rein geschrieben an Code und war immer der Meinung, naja wenn du jetzt das fertig entwickelt hast, dann suchst du nach allen TO dos und arbeitest die ab. Du kannst dir vorstellen wie oft ich nach den TO dos um Code
gesucht hab ne zweimal und nee. Ich wollte einfach mal die Zahl darauf werden, ja. Danke, dass du mich so positiv darstellen möchtest. Lein und jetzt ist es halt so, dass man sich halt da doch zeitnah, also wirklich vielleicht nicht direkt drum kümmert.
Aber zumindest wenn die Implementierung an sich durch ist, dass man danach auch das gleich macht und dann nicht sagt, OK, Features erstmal fertig und das ist auf jeden Fall ein Riesenschritt in die richtige Richtung und weg von diesem Prinzip, ne. Also ich finde das ist halt auch sehr viel mit Disziplin zu tun am Ende sich wirklich zu sagen, weil es ja auch teilweise Sachen, wo man sich dann auch.
Bücher eben schon auch meinte, so habe ich jetzt eigentlich nicht so Bock drauf, dass mich darum zu kümmern. So, es gibt ja auch geile Aufgaben, dann vielleicht auf jeden. Fall Es hat extrem viel mit
Disziplin zu tun. Und das ist halt ne große Voraussetzung, weil wir auch gesagt haben, wie kann man damit umgehen, ne um damit man sowas nicht aufkommen lässt und ich glaube das ist schon wichtig, dass man da eben die Disziplin an den Tag legt zu sagen, OK, du arbeitest dann irgendeine Aufgabe, entdeckst was, wie zum Beispiel mögliches Refactoring oder to do, was man abhaken. Könnte oder vielleicht auch weiß
ich nicht. Man hat noch im Kopf, OK, theoretisch könnte man das und das noch absichern. Oder, oder. Hat irgendein Edge Case entdeckt, der vielleicht irgendwie jetzt nicht so präsent war, dass man sich dann irgendwie aufschreibt und dann sofort, wenn man fertig ist mit dieser Aufgabe, die man gerade bearbeitet hat, sich dann wirklich an diese Dinge setzt, und das erfordert eine Menge Disziplin. Ich weiß ich zum Beispiel auch mal, was ich auch mitgekriegt
hab. In der Vergangenheit ist, dass es auch nicht schlecht ist, wenn man sowas mitkriegt und sowas sieht, entdeckt, dass man dann sich nicht selber einen eigenen Zettel schreibt, wo man sagt, OK, das mache ich irgendwie noch beziehungsweise auch wenn man wirklich sagt, ich mach jetzt direkt danach ne, dass man aber nicht den kleinen Zettel schreibt, sondern dass man das vielleicht irgendwie oftmals hat man ja im Team so ein Board, wo bestimmte Tickets diese diese
Features, Tickets, User Stories sie nennen mag drin stehen. Dass man dann einfach quasi zugänglich für alle Entwickler und Entwicklerinnen im Team dieses. Die. Diese diese, diese diese to do sag ich jetzt mal ne irgendwie aufschreibt. Also das hattest. Du da jetzt gedanklich bei Tickets, dass du quasi ein Backlog, dann Tickets hast. Ich frage jetzt mal wirklich ne genau da oder sag ich mal in irgendwelchen. Chats oder?
Nee, im im du hast den Backlog also also hatten wir das mal gemacht, ich kenne das beziehungsweise mal, dass man es gibt, wir hatten dann so n bisschen Unterteilung zwischen einer User Story im Bug und einem Chor und ein Tor ist dann zum Beispiel sowas wie du veränderst zwar nicht die. Den User Value, das heißt der User kriegt nicht mit, dass etwas verändert wurde, aber es wurde quasi technisch besser
gemacht. Ne und solche Sachen, also was wurde dann darunter gepackt und dann hattest du selbst wenn du es selber vergessen hast, konntest du entweder selber wieder sehen oder jemand anders konnte sehen wenn er Zeit dafür hatte, konnte das gehen und dann bearbeiten. Wichtig an der Stelle ist natürlich ne gute Beschreibung an dieser also. Zu diesem Chor sagt. Das halt doch ein anderer quasi bearbeiten kann. Aber sag mal, ist euer Backlog dann übergelaufen oder habt ihr
es wirklich bewältigen können? Das ging eigentlich ziemlich gut. Also das hat eigentlich ganz gut funktioniert und. Da ist natürlich die Gefahr, denn einfach das einfach das ganze Backlog voller Tickets ist und du quasi deine to do Liste nur quasi auf einen anderen Service ja. Aber wie gesagt, also da ist natürlich wieder der Faktor Disziplin. Spielt da mit rein, definitiv also.
Unterhalt ist ein guter Punkt. Auch weil du meinst, Disziplin, wenn man das einfach mal so sieht, ne, das ist deine Software und du entwickelst diese Software, dann liegt es ja auch in deiner Verantwortung, dass die Rundläuft und quasi in
einem guten Zustand ist. Ja, und wenn jetzt quasi der Druck von außen kommt, dass du quasi ja wir brauchen mehr, also quasi die Stakeholder, die quasi die Anforderungen an dich geben, die sagen hier, das brauchen wir und bis nächste Woche machen wir bis morgen, weißt du also wenn du so richtig Druck drauf kriegst Es ist ja trotzdem in deiner Verantwortung als Entwickler zu sagen, Nein halt Stopp. Das bleibt hier alles sauber, das bleibt alles so wie es sein.
Aber weißt du, dass du einfach sagst, nein, ich trage die Verantwortung für diese Software und ich will nicht, dass jetzt hier die völlige Anarchie ausbricht, weil das genau dieses Gesetz besagt ja im Endeffekt, dass Anarchie ausbricht für dich, weil umso weiter du in diese Richtung läufst, ne und so weiter und so weiter umso schlimmer wird das ganze und du kriegst irgendwann nicht mehr eingefangen, ja dann, dann sind es halt so historische Sachen und da gibt es diesen
wunderschönen Ausdruck, den ich echt zum Kotzen. Ich finde ja ist historisch gewachsen. Was bedeutet bitte, es ist historisch gewachsen, ist das ne Ausrede oder Entschuldigung dafür, dass super viel Müll in der Software? Ist also historisch gewachsen.
Ist für mich auf jeden Fall immer, wenn jemand historisch gewachsen sagt zu einer Software, dann ist es einfach ein liebenswürdiger Ausdruck für dass es dir die größte Scheiße, also klingt, ein bisschen gemein, aber so, das ist meine interne Übersetzung, also das ist so, wie wenn man zum Beispiel sagt, er war stets bemüht.
Ja, das heißt auch nur sowas wie die Person kriegt es nicht geschissen, hat aber immer wieder versucht so, also sehr fleißig, aber halt ohne Erfolg. Und dabei muss es halt nicht mal direkt an die Entwickler, also an den Entwicklern selbst liegen. Na gut, vielleicht mit ihrer Disziplin und ihren verantwortlichkeits Gefühl. Ja, das muss das nicht. Ne, aber das ist ja meistens, weil alle immer mehr sprinten wollen und irgendwie Zeitpläne vielleicht zu knapp kalkuliert wurden, oder?
Es gibt ja so. Viele Gründe, warum das Eintritt. Also ich herauszukommen. Das ist halt dann, das ist dann wirklich die Schwierigkeit und deswegen gar nicht erst in die Richtung gelaufen. Also das sagt ja im Prinzip das Gesetz aus.
Es ist ja wie gesagt OK, wenn man von außen diesen Druck bekommen heißt es macht, man macht mal schneller, mal schneller ist normal würde ich sagen ne, auch wenn es nicht schön ist, aber man muss halt irgendwie damit dealen können und ich finde den Punkt den du gesagt hast sehr wertvoll, dass man wirklich seine, also es ist ja die eigene Verantwortung eines Softwareentwickler oder Software Entwicklern zu sagen OK. Die Qualität der Software, darum
kümmere ich mich und das ist wichtig, das ist, das ist die Aufgabe, die man, die man hat und wofür man ja quasi auch, sag ich mal, steht und deswegen das zum Beispiel, weil ich meinte, ne, ich hab ja auch ne Menge Diskussionen darüber geführt, dass man keine Workarounds einbaut, einfach genau um diese, diesen Qualitätsanspruch. Ne einfach zu gewährleisten und das ist ja auch so, wie wenn man jetzt zum Beispiel sagt, OK keine Ahnung, du hast ja auch nicht in, also in einer Stadt,
irgendwie kommen irgendwie Leute reißen irgendwo eine Baustelle auf und lassen die stehen, sind gerade bei der Hälfte und sagen ja, komm jetzt kommt nächste Baustelle kommt, da reisen wir auch nochmal auf so also du musst ja irgendwie auch abschließen oder? Keine Ahnung, dann auch wieder sozusagen die Baustelle ordentlich zu machen und nicht einfach nur ne Platte drüber legen weißt du also das sind ja Sachen. Das natürlich auch teilweise.
Realität ist, dass die Baustellen siehst du einfach niemand arbeitet wochenlang aber erstmal alles absperren und aufreißen. Ich wusste, dass das jetzt. Kommt aber was ich weiß, ist nicht nur in der Software Entwicklung so, aber was ich. Meine überall, du willst, du warst ja nicht haben und im Normalfall, also bei sowas kann man sich das auch noch ein bisschen besser vorstellen, dass du sagst, das würde ja keiner so machen, ne oder was?
Was ich da auch sehr interessant finde, wenn man das mal so
betrachtet. Du hast quasi sag ich mal, ich nenne es mal dein Chef oder halt deine Kunden die Anforderungen haben ne, also die wollen irgendwas umgesetzt haben und die können ja gar nicht abschätzen was es bedeutet jetzt da so durch zu rutschen und das irgendwie zu implementieren damit erstmal läuft dieses berüchtigte erstmal ne weil die sagen OK läuft erstmal in Ordnung ist mir egal was das also die kennen nicht die Auswirkungen die irgendwann auf
dich zurückfallen werden ne ne und du als Entwickler weißt es aber es ist deine Verantwortung das zu wissen und quasi. Nach außen oder quasi dem Kunden gegenüber vermitteln zu können oder dem Chef oder wem auch immer deinen Product owner. Ja sei es drum ne und das ist halt der entscheidende Punkt und da hab ich halt auch mal extrem geile Analogie gelesen.
Wenn du als Patient zum Arzt gehst, ne und ihm sagst ne Pass auf heut mal bitte nicht desinfizieren, ich hab keine Zeit, ich will jetzt einfach nur aber keine oder irgendwas kriegen heute zacki zacki ich hab keine Zeit ne dann sagt der Arzt ja auch nicht alles klar sie haben keine Zeit, sie können auch schon wieder gehen, das Ding ist umarmen. Auch die Spritze gleich mit. Oder so weißt du, und diese Analogie ist einfach so extrem aussagekräftig, weil es einfach
genau das gleiche ist. Der Arzt würde ja niemals darauf verzichten, zum Beispiel erstmal zu desinfizieren. Klar, das frisst Zeit, aber es muss ja alles seine Ordnung haben, er weiß welche Gefahren entstehen, wenn er es nicht tut und der Patient eventuell nicht. Und das ist genau das Gleiche. Und diese Analogie fand ich einfach so geil.
Deswegen wollte ich mit dir teilen und natürlich auch mit dir, lieber Zuhörer und liebe Zuhörerinnen, weil das bringt es einfach auf den.es ist ja deine Verantwortung, du bist der Experte in der Softwareentwicklung und du musst einfach dafür sorgen, dass alles seine. Richtigkeit hat definitiv. Also finde ich auf jeden Fall sehr gut ist ne. Ne geile Analogie. Ich glaube, das hat die ganze Sache nochmal auf den Punkt
gebracht. Mir bevor wir jetzt abschließen die Folge zu leblanc law, lada equals never. Ja, ist geiler Titel. Möcht ich dich mal fragen.
Wer ist denn der leblanc? Ja, das ist eine spannende Frage. Wir haben ja recherchiert im Vorfeld, weil ich wollte natürlich super vorbereitet sein, also dieses Zitat ist bekannt und das ist auch aus einem sehr guten Buch. Falls Interesse besteht, können wir das auch gerne mal nennen, aber das lasse ich jetzt mal offen und wir wollten halt einfach mal quasi recherchieren, von wem das Zitat eigentlich original ist. Aber das ist sehr schwierig und wir haben es nicht gefunden
werden. Der eigentliche Autor ist, sondern nur denjenigen, der das zitiert hat in seinem. Buch, Das ist halt witzig. Es ist halt, das heißt immer, es ist ein, sag ich mal, in ein Konzept oder Gesetz, was in der Softwareentwicklung oder in der Informatik halt eben bekannt ist. Und das heißt aber, wenn du halt irgendwie leblanc oder Le Blanc oder wie man das ausspricht, Googelst es gibt dieses dieses, es gibt diesen Satz, es gibt aber gefühlt zumindest sind wir zu blöd dafür gewesen.
Herauszufinden, keine Person, die dahinter steht, also weiß ich nicht. Ist schon interessant. Also wenn jemand weiß wer diese Person ist, dann sagt uns das bitte mal. Bitte dann bei uns melden. Wir wollen es. Unbedingt wissen, das wäre echt cool. Genau. Ansonsten würde ich sagen, ja, haben wir doch ganz cool besprochen, würde ich sagen, hat wieder mega Spaß gemacht, fabi, ich würde ja auch die Folge quasi dabei belassen. Was meinst du ja? Ich hab nichts mehr hinzufügen.
OK, sehr gut. Ja dann würd ich sagen, liebe Zuhörerinnen, liebe Zuhörer, falls ihr diese Folge gefallen hat, abonniert doch gerne. In diesem Podcast lassen Like da meld dich auch gern bei uns auf den anderen Plattformen um und zum Beispiel zu sagen, Wer dieser Le Blanc ist oder falls du auch noch Anmerkungen und Beispiele zu diesem Thema
hattest. Oder hast die Links findest du in den Show Notes. Ansonsten würde ich sagen bis zum nächsten Mal. Es hat wieder ne Menge Spaß gemacht Deine Coding Bodies gemeinsam besser.