Latest / Coding Buddies | Tech & Dev-Mindset / Jetzt oder Nie! LeBlanc's Law

Transcript

Jetzt oder Nie! LeBlanc's Law · Coding Buddies | Tech & Dev-Mindset

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