Latest / Coding Buddies | Tech & Dev-Mindset / #159 Der größte Irrtum über 80/20 Lösungen

Transcript

#159 Der größte Irrtum über 80/20 Lösungen · Coding Buddies | Tech & Dev-Mindset

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