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.