Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Okay, genau.
Ja, was soll ich zu Tidy First sagen?
Nee, du solltest dich noch mal kurz vorstellen, weil du warst stumm.
Das war das Problem, ein Teil des Problems, genau, sorry.
Nee, okay.
Also ich bin IT-Consultant bei der Concentric, habe mich auf Software-Qualität spezialisiert, bin aktiv in der Software-Craft-Community, Softwerkskammer, mache Meet-Ups und unterrichte ab und zu Software-Quality-Assurance an der FH.
Genau, und das Thema soll Tidy First sein.
Das ist dieses wunderbare Buch von dem Kent Beck, hier haben wir es, und da haben wir bei der letzten Episode diskutiert, so den ersten Teil, da geht es halt so um den Code-Ebene, da hat Marco netterweise seine Präsentation uns zur Verfügung gestellt und das haben wir da diskutiert.
Kent ist halt bekannt als einer der Erfinder von Extreme-Programming, hat bei Facebook lange Zeit gearbeitet, hat verschiedene andere Bücher geschrieben, zum Beispiel zu Small-Talk-Patterns, ist nur das Zeichnungs-Eingeben-Manifest und Wiederentdecker von Test-Driven-Development, hattest du gesagt, Marco, glaube ich?
Ja, richtig, also er sagt von sich selbst, er ist nicht der Erfinder, sondern der Wiederentdecker, weil er das Konzept eben in einem alten Buch aus den 50er, 60er Jahren entdeckt hat und hat es auf moderne Programmiersprachen übertragen, hat dann S-Unit geschrieben und später dann J-Unit und damit kam der Stein ja erst so richtig ins Rollen.
Genau, und was ist dein Verhältnis zu dem Buch?
Ja, ich habe mich an der Übersetzung beteiligt, also der Verlag wollte jemanden haben, der halt so ein bisschen in der Community drin ist und der eben weiß, wie der deutsche übliche Sprachgebrauch von verschiedenen Begrifflichkeiten ist und da habe ich einfach unterstützt bei der Übersetzung, habe ein bisschen fachlichen Beirat dazu gegeben.
Genau, und dein Statement ist hier hinten auch auf dem Cover drauf.
Code-Aufräumen ist essentiell, aber wann und wie viel?
Tidy First gibt Antworten aus unterschiedlichen Perspektiven, nicht nur für Entwickler.
Ich habe das Buch kostenlos von d.punkt bekommen, einfach deswegen, weil ich ab und zu für d.punkt so ein paar Dinge mache, also irgendwelche Konzepte mir halt anschaue und im Rahmen dessen habe ich halt so ein Kontingent von Büchern, die ich irgendwie kostenlos bekomme, da hatte ich mir das halt irgendwie geholt.
D.punkt gehört zur Heise-Gruppe und Heise ist ja eine der Webseiten, die dankenswerterweise den Stream announcen.
Niemand hat mit uns inhaltlich darüber gesprochen, aber dadurch sind sozusagen die Rollen erstmal klar.
Das Buch hat 120 Seiten, du hattest gesagt, das kann man dann am Nachmittag lesen, das würde ich auch denken, das ist auch irgendwie positiv.
Es gab bei dem Youtube-Video noch zwei Kommentare, und zwar vom letzten Mal, da gab es einmal den Kommentar von IamTheSlime, der schrieb, ich finde diese Patterns herangehensweise spannend.
Ist es wirklich so schwierig, diese Dinge intuitiv zu machen?
Also klar, man hat dann einen Namen, um darüber zu sprechen, aber was passiert, wenn ich eine Änderung vornehmen will, die jetzt nicht im Buch steht, mache ich da etwas falsch?
Das fand ich eine gute Zusammenfassung von dem, was wir, glaube ich, beim letzten Mal diskutiert haben.
Also nein, erstmal macht er nichts falsch.
Und ich finde, die wesentliche Nachricht in Bezug auf die konkreten Patterns ist, die sind eben nicht intuitiv, sonst wäre es ja nicht notwendig, ein Buch zu schreiben, oder zumindest Kent findet die nicht intuitiv, deswegen hat er sie in einem Buch zusammengeschrieben.
Und das finde ich auch ehrlich gesagt ein bisschen schade, weil ich würde mir eigentlich wünschen, dass EntwicklerInnen typischerweise diese Patterns einfach kennen.
Und wir hatten, glaube ich, beim letzten Mal auch über Refactoring gesprochen.
Das ist ein Buch, das ist 25 Jahre alt, Teile, das hat ähnliche Ideen.
Refactoring stellt halt auch noch Änderungen von Verhalten dar.
Hier ist es nur Verbesserung von Lesen, von Lesbarkeit von Code im Wesentlichen.
Und von daher sind das eigentlich Ideen, die sich länger durchgesetzt haben sollten, aber nicht offensichtlich muss man ein Buch schreiben.
Also ich würde jetzt nicht ausschließen, dass man das ein oder andere Konzept irgendwo im Projektalltag auch einfach mal aufschnappt.
Insofern ist diese Sichtweise, dass man auch mit einer gewissen Intuition sich dahin entwickeln kann, durchaus nicht falsch.
Aber ich denke, es hat einen Wert, die Patterns einfach mal strukturiert alle aufzuschreiben, dass man die Chance hat, die eben auch wirklich konzentriert zu lernen und versteht, was es da in diesem Umfeld gibt.
Und der Name, genau, das war ja auch im Kommentar, hilft natürlich tatsächlich darüber zu reden.
Genau, und dann gab es noch ein Kommentar ebenfalls bei YouTube von dem Michael Schürig.
Und der hatte geschrieben, mein Haupteinwand gegen das besprochene Buch ist, dass es bessere gibt.
Zwei davon hat Ken Beck selbst geschrieben, nämlich Smalltalk Best Practices 97 und Implementation Patterns 2008.
Da muss man dazu sagen, also ich verlinke die Bücher auch nochmal, Implementation Patterns hat so Grundlagen der Implementierung, also Klassen, Frameworks, Methoden, solche Sachen.
Ich habe jetzt ehrlich gesagt nur das Inhaltsverzeichnis mir angeschaut.
Das ist was anderes.
Also hier geht es halt um Lesbarkeit von Code.
Und wir haben zum Beispiel beim letzten Mal diskutiert darüber, dass man halt eine Variable, die Initialisierung mit der Deklaration zusammenpackt, damit man nicht irgendwie dazwischen Code hat, der irgendwie wahnsinnig irgendwas anderes beachtet, sondern dass man sozusagen nicht umschalten muss mental.
Und das ist, glaube ich, was anderes als diese Konzepte.
Smalltalk Best Practices sah für mich ähnlich aus, also im Prinzip OO-Grundlagen.
Und das andere Buch, was der Michael Schürig erwähnt hat, ist The Art of Readable Code 2018 von Dustin Boswell und Trevor Fauchier.
Das kenne ich nicht, ich verlinke es irgendwie auch nochmal.
Ich wäre nicht überrascht, wenn es andere Bücher gibt, die da irgendwie besser sind.
Das kann sehr gut sein.
Ich weiß nicht, wie du es siehst, Marco.
Ich wäre da nicht überrascht.
Also ich kenne jetzt kein anderes Buch, was genau dieses Set von Ideen und diesen Fokus hat.
Insofern weiß ich jetzt auch nicht, wie ich das vergleichen kann.
Aber natürlich kann es Bücher geben, die besser sind und ich kenne sie einfach nicht.
Vielleicht ist eine wichtige Nachricht, das haben wir beim letzten Mal nicht so gesagt.
Die Lesbarkeit von Code ist so wichtig, das ist ja auch eine Aussage, die da rauskommt, dass man darüber ein Buch schreiben sollte.
Und das würde ich tatsächlich unterschreiben.
Finde ich nachvollziehbar.
Gut, worum soll es heute gehen?
Wir hatten ja beim letzten Mal diese Code-Ebene und was der Kent noch geschrieben hat, sind zwei Teile.
Das sind mehrere Kapitel.
Einmal zu dem Thema mit dem Managen und zum anderen zur Theorie.
Und die sind so ein bisschen abstrakter und vielleicht auch grobgranularer.
Und da wollen wir eben dieses Mal drüber sprechen.
Und das Erste, was er dort hat, ist die Frage, soll ich Verhaltens- und Struktureränderungen in verschiedenen Pull-Requests machen?
Und da ist seine Aussage, ja, sollten wir prinzipiell erstmal tun.
Dazu habe ich tatsächlich auch eine Folie vorbereitet.
Das ist eine Grafik aus dem Buch, die ich abgemalt habe.
Und da sagt er, es gibt Verhaltensänderungen.
Also ich mache irgendeine Änderung im Verhalten.
Ich implementiere ein neues Feature oder irgendeine Fix im Bug, was auch immer.
Und das ist hier mit so einem V angedeutet.
Und dann gibt es Strukturänderungen, wo ich also tatsächlich jetzt sage, ich ändere den Code, aber nur so, dass er lesbarer wird und besser aussieht letztendlich.
Und ich strukturiere dann eine Verhaltensänderung oder mehrere in einem Pull-Request und getrennt davon Pull-Requests, die sich um Strukturänderungen kümmern, sodass eben niemals in einem Pull-Request Verhaltensänderungen und Strukturänderungen gemischt sind.
Also diese türkisen Kästchen sind Pull-Requests und in einem Pull-Request sind entweder eine oder mehrere Strukturänderungen oder eine oder mehrere Verhaltensänderungen, aber niemals beides kombiniert.
Das ist ja auch nochmal so ein bisschen eine andere Sichtweise auf ein schon länger bekanntes Konzept, dass man ja bei der Entwicklung von mehreren Hüten spricht.
Dass man sagt, ich habe jetzt einen neues Verhalten Hut auf und also einen Entwicklungs Hut auf und jetzt habe ich einen Refactoring Hut auf und kümmere mich eben gezielt um das eine und versuche diese verschiedenen Tätigkeiten nicht zu vermischen.
Weil das ist ja immer eine große Gefahr.
Ich bin gerade dabei ein neues Feature zu implementieren, dann fällt mir irgendwas im bestehenden Code auf, fange an zu refactoren und verliere mich dann im Refactoring.
Dass man einfach eine strikte Trennung macht zwischen welche Tätigkeit führe ich denn jetzt gerade durch.
Genau und das eben idealerweise auch durch Tests absichere, sodass ich eben am Ende einer Verhaltensänderung eben wieder einen grünen Test habe, aber eben einen anderen, weil irgendein Verhalten muss sich ja geändert haben.
Und am Ende nach der Strukturänderung habe ich eben immer noch grüne Tests, aber ich habe halt keine neuen Tests, weil das Verhalten eben genauso ist wie vorher.
Ja, viel mehr gibt es dazu eigentlich nicht zu sagen.
Ich muss halt gestehen, ich finde das auch, ich will nicht sagen, also für mich ist das einsichtig, aber ja, keine Ahnung.
Ich würde vielleicht noch eine Sache ergänzen oder kommt wahrscheinlich später.
Das Entzerren, ist das nochmal ein eigenes Thema?
Genau, das haben wir gleich noch.
Entwirren heißt das Ding.
Entwirren, ja.
Beziehungsweise können wir jetzt irgendwie sozusagen hinspringen, weil das passt tatsächlich inhaltlich ganz gut.
Also entwirren bedeutet halt, du hast es ja gerade gesagt, Marco, ich habe ja möglicherweise das Problem, dass ich halt Verhaltensänderung mache, Strukturänderung und das ist halt irgendwie alles zusammen und irgendwie unlogisch und wirr.
So und da gibt es halt drei Möglichkeiten.
Also der Klassiker vielleicht erstmal, um das abschließend zu erklären ist, also man landet oft in der Situation, ich habe einfach Code, der ist vielleicht noch nicht mal committed, das heißt, der ist in der IDE irgendwie wieder als modified angezeigt und ich kann jetzt einfach nicht mehr unterscheiden, welche dieser Modifikationen tragen denn jetzt eigentlich zu was bei.
Das ist so die Situation, in der man auf einmal steht.
Okay, ich hätte jetzt gedacht, okay, ja, also ich habe ich habe noch nicht mitgemacht.
Ja, ob man von Pull-Request redet oder von Commits, du hast das auf beiden Ebenen das Problem.
Ja, aber also ich sage mal, dass das stärkere Problem ist, wenn du sogar im gleichen Commit nicht mehr unterscheiden kannst, welche Modifikation ist welcher.
Du hast einfach gearbeitet, hattest deinen Fokus auf den Code, auf das Problem und hast in dem Moment nicht daran gedacht, im richtigen Zeitpunkt ein Commit zu setzen.
So und jetzt stehst du halt vor einer Situation, du hast Modifikationen und kannst die jetzt auf einmal nicht mehr zuordnen.
Genau, das heißt also, ich habe weder V noch S in dieser Grafik hier, also weder eine Faltensendung noch eine Strukturänderung, sondern ich habe etwas Gemeinsames und bin jetzt kurz davor zu sagen, nicht, geht Commit, bin es Strich A möglicherweise.
Und die andere Möglichkeit wäre, dass ich gesagt habe, okay, ich habe jetzt irgendwie verschiedene Commits und jetzt will ich einen Pull-Request machen und das ist da irgendwie auch drin gemischt.
So und jetzt gibt es eben drei Möglichkeiten, so sagt das Buch.
Ich kann das halt so losschicken, wie ich es halt habe, also sprich unaufgeräumt.
Ich kann das entwirren, also nochmal mit irgendwelchen Git-Werkzeugen und so weiter dafür sorgen, dass ich eben die zwei Commits mache oder eben zwei Pull-Requests, die halt dann sozusagen Sortenreihen sind oder ich werfe es weg und mache es nochmal neu.
Und dazu hattest du, glaube ich, eine starke Meinung, nicht?
War es nicht so?
Das war, glaube ich, der Punkt an der Stelle.
Die Meinung kommt jetzt nicht nur von mir, sondern auch von Kent Original aus dem Buch, aber ich würde das unterstreichen.
Also klar, wenn man wenig Zeit hat, kann man natürlich sagen, ich shippe das alles auf einmal.
Das ist natürlich die günstigste Lösung, aber es ist halt auch die schlechteste Lösung, weil du natürlich dann nachher das Problem hast, das ist schlecht für den Reviewer, der nicht auseinanderhalten kann, was da passiert.
Und es ist ungünstig, wenn man halt nachher doch mal nochmal irgendwas cherrypicken will oder wenn man verstehen will, was da eigentlich passiert ist.
Also es hat auf jeden Fall Konsequenzen und die willst du eigentlich nicht haben.
Deswegen sind die beiden sinnvollen Lösungen entweder, okay, ich nutze halt wirklich Git-Tools, um das zu entwirren.
Das kann aber schiefgehen, das bringt ein Risiko mit sich.
Oder, und das ist laut Kent die Lösung, die er auch präferiert und die würde ich auch immer präferieren, ist zu sagen, ich werfe das weg und mache das neu.
Das klingt erstmal total unintuitiv, weil du hast ja Zeit reingesteckt, du hast ja Arbeit reingesteckt und jetzt musst du das auf einmal wiederholen.
Aber also meine persönliche Erfahrung ist die, wenn ich was gemacht habe und ich mache es gleich danach nochmal neu, dann bin ich drin und meistens mache ich es sogar besser als beim ersten Mal.
Ich wiederhole ja nicht unbedingt die Fehler, die ich beim ersten Mal gemacht habe und kann dann eben auch mich stärker darauf konzentrieren zu entscheiden, wo setze ich jetzt die Schnittpunkte, wo mache ich meine Commits, wie ordne ich die Commits dann den Pull-Requests entsprechend zu.
Also es wird beim zweiten Mal eigentlich immer besser und die Zeit, die du verlierst, ist oft nicht hoch, weil die eigentliche Arbeit, die steckt ja in den Überlegungen, in den Gedanken, die du dir beim ersten Mal gemacht hast und die hast du nicht verloren.
Was du verloren hast, ist ein bisschen physikalische Tipparbeit und das ist nicht das Bottleneck.
Genau, also dem ist sozusagen aus meiner Sicht nichts hinzuzufügen, außer dass ich eben tatsächlich auch diese Option spannend und interessant und gut fand.
Ich muss sagen, ich fand sie etwas weniger, also ja, für mich ist das halt eben, glaube ich, so ähnlich wie bei dir auch eine Option, die halt sehr viel Sinn macht.
Also es geht nicht darum, Code zu produzieren, es geht nicht darum, Code einzutippen, sondern es geht irgendwie um was anderes.
Es geht halt darum, strukturiert vorzugehen und eben hier auch insbesondere anderen Menschen das halt klar zu machen.
Also Code ist irgendwie Kommunikation an der Stelle.
So, dann das andere Pattern, was er halt, ich glaube, damit haben wir es nicht, mit getrenntes Aufräumen und diesem Ding mit dem Entwirren.
Dann hat er ja diese Sache mit dem Verketten, wo ich ihm sage, dass ich mehrere Aufräumereien hintereinander mache.
Also ich baue zum Beispiel einen erläuternden Kommentar ein und dann baue ich aber statt dem erläuternden Kommentar einen variablen Namen.
Oder ich führe halt eine Konstante ein oder eine Hilfsroutine.
Also man kann manchmal solche Sachen machen wie einen Code extrahieren, um diesem Ding einen Namen zu geben, damit das halt irgendwie klar ist.
Und dann würde ich halt eben erst den Kommentar machen und dann eine Strukturänderung im Code, sodass der Code das halt besser reflektiert.
Oder ich kann eben, ich habe irgendwie eine Unstrukturierung im Code, dann gruppiere ich erstmal die Anweisung, füge erläuternde Kommentar hinzu und extrahiere eine Hilfsroutine.
Sodass das eben bedeutet, dass ich mehrere Dinge mache, die schrittweise das halt sozusagen verbessern.
Das ist auch ein Vorgehen, was, glaube ich, bei Refractoring total wichtig ist.
Ja, also eine Verkettung, die ich sehr spannend finde, also es gibt da ein Tidying oder eine Aufräumerei, die haben wir das letzte Mal gar nicht mehr besprochen.
Die heißt ein Haufen, das ist so ein bisschen das Gegenteil zu Extract Method, wo du Sachen sogar gezielt zusammen kopierst.
Warum?
Weil vielleicht im ursprünglichen Code eine schlechte Abstraktion gewählt wurde.
Weil vielleicht die Art und Weise, wie der Code strukturiert ist, in Funktionen, vielleicht sogar Klassen aufgeteilt ist, einfach schlecht ist, um ein Verständnis darüber zu bekommen, um was es da geht.
Und dann machst du sogar erstmal das Umgekehrte.
Du wirfst Dinge zusammen, was den Code ja potenziell sogar schlechter machen könnte, aber um hinterher ein Verständnis zu haben, wie man es dann eben mit einer anderen Abstraktion hinterher wieder besser aufbereitet.
Und dann hast du eben diese Verkettung von einem, also ein Haufen heißt es im Deutschen, diese Aufräumerei von der und dann eben einem Extract Utility Method oder Extract Method heißt es ja klassisch im Refactoring.
Oder anderen weiteren Naming verbessern etc., die dir helfen, dann wieder mehr Klarheit zu bekommen.
Genau, perfekt.
So, dann haben wir das Thema mit den Batchgrößen.
Achso, nee, sorry.
Also erstmal, da war noch ganz viel Hinweis zu dem Audio.
Genau, danke.
Das haben wir jetzt also offensichtlich gelöst.
Und YouTube hat gerade geschrieben, AnkerBob ist leider in den letzten Jahren ein bisschen abgedrischt von dem, was man als Normalverhalten bezeichnen würde.
Genau.
Nicht.
Und er schreibt, aber CleanCode behandelt auch solche Aspekte, die auf Lesbarkeit von Code zielen.
Okay.
Ist, glaube ich, auch noch eine interessante alternative Quelle.
Und CleanCode hört sich auch nach Lesbarkeit an.
Ja, das Buch ist sehr umstritten, um es mal vorsichtig auszudrücken.
Also es ist auch sehr opinionated.
Aber vielleicht ist das eine Diskussion, die man auch jetzt nicht führen muss.
Also vielleicht hast du zwei Sätze dazu übrig, wo es konkret umstritten ist.
Also Problem Nummer eins ist die Person von Robert C.
Martin selbst, weil er in der Community, also gerade in der Software-Craft-Community, jetzt nicht unbedingt den besten Ruf genießt bezüglich diverser politischer Äußerungen, die er getätigt hat, wo er sich, sage ich mal, eher zu einem rechten Flügel bekennt.
Jetzt gibt es diese Diskussion, kann ich die Inhalte von der Person trennen?
Da kann man natürlich auch wieder unterschiedlicher Meinung dazu sein.
Schwingt das irgendwie mit?
Dann gibt es die Diskussion, wenn man sich dieses CleanCode-Buch mal genau anschaut, welche der Teile hat er denn geschrieben und welche sind contributed worden von anderen Leuten?
Und da gibt es zum Beispiel auch so eine Diskussion, welchen Wert hat denn jetzt welche Contribution?
Und dann sind das halt so Dinge, also Ken Beck sagt zum Beispiel, mal ein Beispiel rauszugreifen, wo es um jetzt eine inhaltliche Diskussion geht.
Also Ken Beck sagt zum Beispiel, also es gibt Leute, die sind eher, wie sagt man, also die splitten, ich glaube er nennt das Splitters, die splitten halt Code möglichst weit auf, um möglichst kleine Code-Stücke zu haben, die man benennen kann.
Und es gibt genau Lumbars, die Code eher zusammenbringen, um große Code-Stücke zu haben, die weniger Abstraktionen brauchen, um sie zu verstehen.
Beide Varianten bringen einen Trade-Off mit sich.
Und oft ist es ja auch situationsspezifisch, was gerade Sinn macht, wie viel Splitting und wie viel Lumping will ich sozusagen gerade in der jeweiligen Situation haben.
Und da stellt sich halt das Clean-Code-Buch zum Beispiel ganz, ganz stark auf die Seite des Splittings. sehr opinionate und sagt, es ist auf jeden Fall immer besser, ein Splitting zu machen.
Und das würde ich halt in dieser generellen Form nicht unterschreiben.
Ich bin persönlich auch eher ein Fan von Splitting tatsächlich und bin großer Fan davon, kurze Methoden zu haben, die einen guten Namen haben, der eben das Was und nicht das Wie der Methode beschreibt.
Das sind alles Dinge, die man da findet.
Aber die sind oft in der Form geschrieben, dass es sehr dogmatisch sind und die Trade-Offs halt nicht immer beachten.
Also das ist so ein Problem, was das Buch auf jeden Fall mitbringt.
Das hat so weit geführt beispielsweise, dass wir bei uns in der Company gesagt haben, wir wollen versuchen, diesen Namen Clean Code auch zu vermeiden, weil an diesem Namen Clean Code irgendwo auch die Marke von Robert C.
Martin hängt.
Und deswegen gibt es den alternativen Begriff Clear Code, der versucht sich so ein bisschen, der sozusagen versucht, das Konzept von der Marke zu trennen.
Das ist so vielleicht ein Aspekt.
Da habe ich aber schon viel zu viel dazu erzählt.
Passt super.
Tutor schreibt 100, ich nehme ein Prozent, die Person Anker Bob ist auch nicht mehr auf meiner Liste mit Personen, die ich bewundere wegen seinem Verhalten in der Community.
Das würde ich halt irgendwie ähnlich sehen.
Wir haben übrigens auch eine Episode gemacht mit dem Daniel Terrors North zum Thema Cupid, was so ein bisschen so ein Gegenentwurf ist zu diesem Solid-Prinzip, was ja irgendwie auch in diesen Bereich reingehört.
Und ich muss mal kurz nachgucken.
Also Solid ist ja auch so ein relativ starker Begriff und Cupid ist Amor, der römische Liebesgott steht jetzt in der Übersetzung.
Ich glaube, es ist kein Zufall, dass da auch ein anderer Begriff jetzt akronym genutzt worden ist.
Die Episode verlinke ich auch noch mal.
Das kann ich vielleicht noch eine Sache dazu empfehlen.
Es gibt von Kevin Haney einen sehr guten Talk, der heißt Solid Deconstruction, der sich sozusagen auch die ganzen historischen Referenzen zu dem Thema noch mal anschaut.
Den kann ich sehr empfehlen.
Ich identifiziere.
Ich kann auch einen Link reinschicken, wenn du magst.
Ja, schick mir lieber eine E-Mail oder so.
Ich packe es halt auf jeden Fall mit in die Note.
Also Timo hat geschrieben, mag ich die Auffassung clear?
Das passt also auch.
Jetzt zurück zu dem, was wir eigentlich sagen, wo wir eigentlich standen.
Wir standen aber bei diesem Thema mit den Badgegrößen und als guter Berater habe ich dafür auch so einen PowerPoint vorbereitet bzw. abgemalt.
Da ist jetzt die Frage, soll ich jetzt pro Badge, also pro Pull Request respektive pro Git Commit mehr oder weniger Aufräumereien machen?
Was Kent schreibt, ist, dass es da zwei unterschiedliche Sachen gibt.
Das eine ist, wenn ich kleinere Badges mache, dann habe ich weniger Kollisionen.
Das heißt, andere EntwicklerInnen laufen mit mir weniger, also nicht machen weniger konkurrierende Sachen, die den Code ändern, den ich auch gerade ändere.
Es ist weniger wahrscheinlich, dass sich das Verhalten ändert und es ist weniger wahrscheinlich, dass ich Dinge aufräume, die ich eigentlich nicht aufräumen müsste, sondern wo ich irgendwie spekulativ einarbeite.
Das heißt also, wenn ich mehr Aufräumereien pro Badge habe, das ist das, was man hier sieht, dann habe ich eben mehr Kollisionen, mehr Interaktion und mehr Spekulation da drin und das bedeutet, die Kosten werden eben höher.
Also wenn ich jetzt was ändere und Marco ändert irgendwie in demselben Code auch irgendetwas und wir haben eine Kollision, dann müssen wir das irgendwie auflösen und das heißt, wir haben nervige Extraarbeit.
Wenn wir weniger pro Badge machen, bedeutet das, dass die Kosten für die Reviews steigen, weil wir eben mehr Reviews machen.
Also pro Badge so die Annahme passiert ein Review, der hat einen mehr oder minder festen Kostensatz.
Das sind so die beiden Sachen, die da sozusagen gegeneinander spielen.
Ich habe vielleicht noch einen anderen Aspekt, den man jetzt hier in dem Graf nicht sieht, also weil natürlich hier nur jetzt die Kosten betrachten werden.
Also ich würde noch hinzufügen, dass wenn die Review Badges kleiner werden, dass dann die Qualität der Reviews auch steigt, weil ja oft das Problem ist, wenn ich zu viel Code auf einmal reviewen muss, dann gibt es ja dieses klassische Durchschwinken, Dinge werden nicht mehr so genau angeschaut oder man reportet noch Style-Issues, statt sich die eigentlichen Thematiken wirklich anzuschauen.
Deswegen halte ich es grundsätzlich für eine gute Idee, kleinere Badges zu haben.
Genau und ich bin mir auch nicht sicher, also wenn ich mich jetzt richtig erinnere, ist tatsächlich die Arbeitshypothese, dass halt Reviews im Wesentlichen eine konstante Kosten haben und das finde ich ehrlich gesagt komisch.
Aber sei es drum.
Du hast es vorhin schon gesagt, du bist eher ein Splitting-Proponent.
Ich glaube, der Punkt ist halt, dass es da eben unterschiedliche Gründe gibt für das eine und das andere und dass man da sozusagen seine Wahrheit für sich finden muss.
Du hast natürlich einen Overhead, denke ich, pro Review und der summiert sich halt natürlich.
Wenn du größere Badges hast, hast du den Overhead seltener, logischerweise.
Also das ist, denke ich, das, was da mit reinspielt.
Genau und du hattest das im Vorgespräch schon gesagt, also es gibt ja Ansätze wie zum Beispiel Per-Programming respektive Ensemble-Programming, wo ich dann eben gar keine Reviews brauche, weil eben alle eh schon zusammensitzen.
Oder auch eine generelle Geschichte, die auch, sage ich mal, in den Teams, wo ich eigentlich immer sehr beliebt war oder eine Sache, die ich und andere versucht haben einzuführen, ist Trunk-Based-Development.
Das gelingt nicht immer und das passt natürlich auch nicht für jedes Team, aber dass man einfach von diesem asynchronen Pull-Request-basierten Workflow halt schnell kommt, sondern mehr in ein direktes Gespräch geht, um halt ein schnellere Feedback-Zyklus auch zu haben, was solche Review-Themen eben angeht.
Genau, wichtig dabei, Trunk-Based mit T, nicht mit D.
Die extreme Form davon ist natürlich sowas wie Mob- oder Ensemble-Programming, wo du sozusagen die ganze Zeit in einem permanenten Review-Prozess bist.
Genau, der Timo Steuerwald hat gerade geschrieben, kann ich auch nicht nachvollziehen, kleine Reviews macht man ja auch viel lieber, weil sie besser in den Tag integriert sind als große Blobs.
Da kommen wir dann zu dem nächsten Thema, das ist der Rhythmus.
Da ist halt die Aussage Minuten oder Stunden und nicht viel länger für Aufräumen.
Also nicht deutlich länger, also wir reden nicht über Tage, Wochen oder so, sondern eben oft, ständig.
Also Stunden finde ich eigentlich schon übertrieben, ehrlich gesagt, aber sei es drum.
Erst Aufräumen, dann Verhaltensänderungen habe ich hier diskutiert und das gilt halt nicht für strategische Umbauten.
Da gibt es halt den Hinweis auf das nächste Buch, was da wahrscheinlich irgendwie sozusagen argumentieren wird, hoffentlich.
Genau, das haben wir schon diskutiert und dann gibt es halt irgendwie diese Frage mit Vorher, Nachher, Später, Nie.
Also wann soll ich denn aufräumen?
Bevor ich etwas implementiere, also bevor ich eine Verhaltensänderung mache, danach oder irgendwann später oder halt nie.
Und seine Aussage ist, jede von diesen Optionen ist valide, also vorher, damit ich halt das Ding leichter implementieren kann, nachher, weil ich irgendetwas gemacht habe, was halt irgendwie unschön ist und ich es halt aufräumen will, danach, später, weil ich es jetzt nicht aufräumen will, sondern irgendwie gerade wichtige Dinge zu tun haben will oder nie, wenn man es halt nie wieder ändern muss.
Wenn es okay ist, würde ich das noch ein bisschen genauer auseinandernehmen, da noch ein bisschen ins Detail gehen.
Genau, also das Nie ist eine spannende Geschichte, weil das ja erstmal so, also sage ich mal für jemanden, der dem Softwarequalität wichtig ist, ist das erstmal erschreckend zu sagen, nie aufräumen.
Wie kann ich denn behaupten, irgendetwas nie aufzuräumen?
Zumal man ja weiß, dass Software eigentlich solange die Software genutzt wird, wird sie auch weiterentwickelt und man eigentlich nicht davon ausgeht, dass irgendwas so stabil ist, dass ich es nie wieder ändere.
Aber die Aussage an der Stelle ist, es gibt diese Situation, vielleicht wird sich die Software weiterentwickeln, aber es gibt vielleicht einzelne Teile, die bleiben einfach wirklich über den Lebenszyklus der Software ab einem gewissen Punkt einfach stabil und ändern sich nicht mehr.
Das ist selten, aber das kann es geben und dann ist es eine valide Variante zu sagen, ich räume das nicht auf, weil ich fasse es sowieso nicht an.
Also da gibt es ja auch Metriken, die man sich anschauen kann, wie Codechurn beobachten, wie oft wird eine Datei tatsächlich geändert, vielleicht an der Stelle ein Hinweis auf das Buch von Adam Thornhill, das Software as a Crime Scene heißt es glaube ich, das zum Beispiel auch solche Betrachtungen macht, finde ich eine ganz spannende Geschichte.
Genau, das ist der Nie-Punkt.
Der Später-Punkt ist auch spannend, weil das auch so eine psychologische Geschichte ist.
Also oft, wenn man dann so sagt, ja, aufräumen machen wir später, kann das halt auch bedeuten, das wird dann weggeschoben, weil man sich damit nicht beschäftigen will und man macht es dann vielleicht wirklich auch gar nicht, obwohl es notwendig wäre.
Es kann aber auch eine Entschuldigung in die andere Richtung sein und sagen, wenn wir es jetzt nicht machen, dann machen wir das auch später garantiert nicht.
Also müssen wir das jetzt unbedingt sofort machen und dann bist du auf einmal in so einer Situation, wo du anfängst, die Entwicklung zu blockieren, weil du zu viel Aufräumereien auf einmal bündelst.
Kennenzlösung ist zu sagen, er legt sich so eine Funlist an, also er nennt das Funlist, warum auch immer.
Also im Prinzip ein Backlog für Aufräumereien, also dass er sagt, ich schreibe mir auf, was ich tun und versuche die eben auch zu interleaven und an den geeigneten Zeitpunkten kleine Teile aufzuräumen, ohne zu viel Zeit auf einmal zu investieren.
Ich sehe, ich habe gerade ein Feature abgeschlossen, bevor ich mir die nächste Story sozusagen aus dem Tierer-Backlog, was auch immer, nehme, schaue ich erstmal, ob ich vielleicht irgendwo eine Kleinigkeit aufräumen kann in einem vernünftigen Zeitrahmen.
Genau, also verschiedene Sachen, du hattest ja Adam Thornhill erwähnt, wir hatten diese Episode zu Behavioral Code Analysis, es gibt also Möglichkeiten tatsächlich, wer arbeitet, wie mit dem Code, durch Werkzeuge zu untersuchen.
Das ist, glaube ich, eine gute Ergänzung.
Ich finde es auch nochmal wichtig, dass du hingewiesen hast darauf, dass man eben so strategische große Änderungen aufteilen kann und sozusagen in den Refactoring-Alltag reinbekommen kann.
Und es gibt auch eine Episode zum Thema, ja, da kommen wir sozusagen ins Fazit.
Also ich würde behaupten, das hier sind Dinge, die zu Refactoring passen, nicht feingranular, ständig im Hintergrund.
Ich bin mir gar nicht sicher, ob es im Refactoring-Buch so drin stand, von daher ist es tatsächlich was Neues.
Vielleicht, und…
Ich muss noch die anderen beiden Punkte machen, weil es waren jetzt noch zwei Übungen, das kommt jetzt genau da wieder drin vor.
Ach so, sorry, ja, genau.
Und das danach ist eigentlich genau das, was du gerade gesagt hast.
Ich habe Code geschrieben und danach mache ich ein kleines Refactoring in einem begrenzten Zeitrahmen, das ist eigentlich der Idealzustand, den man normalerweise haben möchte.
Ich refactore sofort danach, dann habe ich den Code noch im Kopf, dann ist er noch frisch und mache das eben immer kontinuierlich ein kleines bisschen.
Das ist so eigentlich auch die ursprüngliche Idee von Refactoring überhaupt gewesen.
Genau da sind wir dann quasi schon im Fazit.
Und das Letzte ist halt dieses First, und das ist ja im Prinzip das, was ja auch dem Buchtitel letztendlich vorkommt.
Es ist ja Teil die First, und das würde ich sagen, das ist so ein bisschen Ken’s Signature Move.
In früheren Büchern hat er das Preparatory Refactoring genannt, das heißt, ich muss irgendwas Neues bauen, ich brauche eine Verhaltensänderung, aber bevor ich diese Verhaltensänderung angehe, schaue ich, ob ich vielleicht in der Lage bin, den Code so aufzuräumen, dass ich die Verhaltensänderung dann mit weniger Aufwand durchführen kann.
Und das ist natürlich eine Abwägung, die man treffen muss, und es ist nicht immer leicht zu sagen, spart mir das Zeit jetzt vorher aufzuräumen, aber manchmal kann man es abschätzen, weil man schon sieht, dass der Code nicht die Struktur hat für die Änderung, die ich jetzt machen muss.
Und dann ergibt das natürlich Sinn.
Genau, und Hamburg hat zum einen die Frage gestellt, wie ist denn der Code beim ersten Mal durch ein Review gekommen, und hat dann noch die Folgefrage gestellt, ist denn der Code nach einer Überarbeitung fertig oder muss der alle paar Monate immer wieder angefasst und aufgeräumt werden?
Und ich glaube, das passt ein bisschen zu dem, was du gerade gesagt hast.
Es kann zum Beispiel sein, dass ich damals gedacht habe, hey, so ist der Code gut strukturiert, dann kommt eine Änderung, die ich gerne machen will, und dann wünsche ich mir, dass der Code gut strukturiert ist, und dann mache ich das eben vorher, damit ich die Änderung besser durchführen kann.
Und insofern ist der Code halt irgendwie schon fertig, im Sinne von der Wahrheit mit dem damaligen Wissensstand gut, aber er ist dann eben doch suboptimal.
Und ich weiß nicht, vielleicht ist halt eine Antwort darauf…
Du weißt ja zu einem bestimmten Zeitpunkt noch nicht, welche Features auf dich zukommen.
Du schreibst dir den Code auf dein Modell, auf dein Verständnis, was du in diesem Moment hast, und das kann sich ja ändern aus ganz unterschiedlichen Gründen.
Ich glaube, das ist auch sehr stark verbandet mit diesem, man guckt sich halt den Code an und denkt so, ey, wer hat denn diesen Schwachsinn geschrieben, guckt sich das halt anschließend an und stellt fest, ups, das war ich ja irgendwie selber.
Es gibt auch noch einen schönen Spruch dazu, wenn du dir einen Code anschaust, den du selber vor einem halben Jahr geschrieben hast, und du findest den gut, ist das ein schlechtes Zeichen, weil das bedeutet, du hast in der Zwischenzeit nichts Neues dazugelernt.
Das ist eine ein bisschen übertriebene Aussage natürlich, aber diese Tendenz finde ich gut.
Ich entwickle mich ja auch weiter.
Ich finde das total wichtig, weil das bedeutet, dass es eben dieses Fertig in gewisser Weise nicht so richtig gibt.
Ich kann jetzt damit leben und mache halt weiter, und dann stelle ich halt später fest, beim jetzigen mentalen Modell verstehe ich es halt irgendwie nicht mehr.
Ich muss gerade denken an die eine Person, die halt damals mit Chemikalien Fotos gemacht hat und vergrößert hat, die muss irgendwie sich hingestellt haben und muss irgendwie unglaublich viele Abzüge gemacht haben von irgendeinem Foto, weil sie es halt immer weiter optimiert hat und hat sich es irgendwann nochmal angeguckt und gesagt, hä, wo ist denn der Unterschied überhaupt?
Ich glaube, das ist hier so ein ähnlicher Effekt.
Wenn ich es halt schreibe, bin ich halt in einer anderen Situation und habe eine andere Wahrnehmung als später.
Genau, also subsumiert wäre das halt für mich eben genau diese Geschichte.
Es ist feingranular.
Ich mache es halt ständig als Hintergrundprozess.
Ich mache hier eine Verbesserung der Lesbarkeit.
Es sollte Teil der täglichen Arbeit sein.
Ich würde auch erwarten, dass Techniker das typischerweise tun.
Und wenn ich halt anfange und dafür sorge, dass ich den Druck sozusagen erhöhe, dann wird es halt wahrscheinlich zusammenbrechen.
Tutor hat geschrieben, welches Buch hat Marco erwähnt.
Das ist von dem Adam Thornhill und das heißt Your Code is a Crime Scene.
Den Link auf die Folge mit dem Adam packe ich nochmal rein, dann weiß man, wie man ihn schreibt.
Und da habe ich auch tatsächlich das Buch verlinkt.
Gut, dann kommen wir zu diesem Teil 3.
Da geht es um die Theorie.
Timo hat auch gerade nochmal den Titel reingepackt, das ist gut.
Da gibt es halt zwei Kapitel zu dem Thema vorteilhafte Beziehungen, also Hierarchien und Benutzungsbeziehungen und dann sowas wie Kopplung und Kohäsion.
Ich würde nicht so tief darauf eingehen, das sind so Grundlagen.
Ich sollte entkoppelte Sachen haben, ich sollte möglichst Kohäsion haben innerhalb von Modulen.
Ich will eigentlich in erster Linie sprechen über dieses Thema mit den ökonomischen Grundlagen, weil ich glaube, das ist tatsächlich ein Highlight.
Und zwar sagt er dort im Wesentlichen zwei Sachen.
Die eine Sache, die er sagt, ist, wenn ich die Möglichkeit habe, ich habe jetzt 10 Millionen Dollar, das ist ein Beispiel, und ich gebe dir den Marko, und der Marko sagt mir, dafür kriegst du sofort 12 Millionen, dann würde ich das sicherlich lieber machen, als wenn mir der Marko sagt, ich kriege in 10 Jahren 20 Millionen.
Obwohl es deutlich mehr ist, dauert es länger, bis ich das Geld bekomme.
Und das ist mir deutlich weniger lieb, weil wer weiß, was in 10 Jahren mit dem Marko ist, wer weiß, ob er mir tatsächlich das Geld gibt, wenn er mir sofort 12 Millionen gibt, oder morgen, dann ist das weniger risikobehaftet.
Und das ist die Grundlage, weswegen es Zinsen gibt, und weswegen typischerweise langfristige Zinsen niedriger sind als kurzfristige Zinsen, und ich will letztendlich ganz schnell … viel Geld verdienen.
Und das ist schon so ein bisschen die Grundlage von Ökonomie und Kapitalismus.
Da gibt es aber eine andere Sache.
Ich nehme mal an, ich baue Fahrräder und ich habe jetzt irgendeinen Lieferant.
Also Marco ist halt ein Lieferant und Marco liefert mir halt qualitativ hochwertige Strahlrohre für meine Fahrräder.
Und jetzt kann ich mit Marco einen Vertrag schließen und kann sagen, wenn ich im Winter für den nächsten Sommer die Fahrräder produziere, dann lieferst du mir halt eine große Menge an Strahlrohren für einen Preis, den wir jetzt festlegen.
Und das hat den Vorteil, dass ich jetzt anfangen kann zu planen.
Ich kann halt die Preise festlegen und ich habe halt mein Risiko gemanagt.
Und wenn wir jetzt mal davon ausgehen, dass das Stahl natürlich auch deutlich teurer sein könnte in einem halben Jahr, wir wissen es halt einfach nicht.
Das ist halt genau das Risiko.
Genau.
Tatsächlich ist das auch passiert, wenn ich mich nicht gewaltig irre.
Also ich glaube, als die Chinesen angefangen haben, ganz viel mit Stahlbeton zu bauen, ist halt der Stahlpreis irgendwie hochgegangen.
Wenn die Autoindustrie plötzlich ganz viel Zeug baut mit Stahl, geht die Stahlpreise eben auch hoch.
So ein Risiko habe ich jetzt irgendwie gemanagt.
Und dafür kann ich jetzt eben tatsächlich – also das funktioniert auch zum Beispiel mit anderen Rohstoffen.
Also es gibt ganz viele Sachen über Weizen und Mais und so ein Zeug.
Und das macht halt irgendwie einen Sinn, weil dadurch kann ich eben mein Risiko beschränken.
Nehmen Sie dieses Risiko ab, aber dafür will ich auch was von dir haben.
Genau.
Das würde also bedeuten, ich würde jetzt irgendwie sagen, weiß ich nicht, ich kaufe halt so und so viele Rohre für den Preis und ich gebe dir jetzt 10.000 Euro.
So.
Und dann haben wir eben diesen Vertrag abgeschlossen.
Und das kann man auch tatsächlich tun.
Diese Rohstoffbörsen gibt es ja.
Da kann man jetzt irgendwie genau so ein Handelsgeschäft abschließen.
Und das ist irgendwie zum Absichern von, weiß ich nicht, einer Bäckerei ist vielleicht gut Weizen zu kaufen an Optionen.
Ich finde, das benutze ich als Metapher für Softwareentwicklung.
Und zwar habe ich jetzt irgendwie die Möglichkeit, eine Entwicklerin hinzusetzen und ihr zu sagen, hör mal zu, baue halt ein Feature.
Und dieses Feature wird halt hoffentlich dazu führen, dass einige Kunden sagen, super, dass dieses Feature da ist.
Das ist wertvoll.
Ich kaufe das Produkt.
Und das bedeutet, ich verdiene halt Geld.
Und ich habe zufriedene Kunden und solche Geschichten.
Und das ist halt eine wahrscheinlich kurzfristige Sache.
Und er sorgt dafür, dass ich halt irgendwie Geld bekomme.
Und die andere Möglichkeit wäre, dass ich jetzt dieser Entwicklerin sage, räum doch mal den Code auf.
Und wenn ich das tue, schaffe ich eine Option.
Das heißt also, ich sorge dafür, dass mein System änderbar ist, damit wir im nächsten Jahr das, was dann ansteht, tatsächlich umsetzen können.
Was eben bedeutet, dass ich jetzt eben investiere in das nächste Jahr.
So wie ich mir jetzt irgendwie Stahlrohre bei Marco kaufe, ist es dann eben so bei dem Code, dass ich dem Marco sage, sorge dafür, dass es aufgeräumt wird.
Und das wird dann nächstes Jahr dafür sorgen, dass wir dazu in der Lage sind, die Software einfacher zu ändern und dann eben Features auszurollen.
Das ist ja auch eine Form von Risikomanagement, um die es da auch wieder geht.
Ich kann natürlich jetzt einfach auf Gedeih und Verderb Features rausblasen und mir da meinen Code aber mit verschlechtern.
Und dann wird es natürlich später richtig, richtig teuer, neue Features zu implementieren, wenn ich weiß, was der Kunde will, vielleicht in einem Jahr.
Und damit haben wir, und das ist genau der Punkt, damit haben wir jetzt die Möglichkeit, auf einer wirtschaftlichen Analogie zu erklären, was bei uns das Problem ist.
Also so wie Technikadapt das ja auch versucht, machen wir das jetzt irgendwie auch.
Und das ist etwas, was man kommunikativ nutzen kann, um Management zu erklären, ja, wir können jetzt irgendwie ganz viele Features rausblasen.
Und ja, das wird auch dazu führen, dass wir ganz viele glückliche Kunden haben.
Aber in einem bestimmten Zeithorizont, dann knallt das gewaltig, weil dann können wir eben nicht mehr.
Und du hast jetzt die Wahl.
Du kannst jetzt entweder sagen, wir ändern das.
Also wir machen jetzt eine Verhaltensänderung.
Das sorgt für Kunden.
Oder wir machen eine Strukturänderung.
Das sorgt dafür, dass wir mehr Optionen haben.
Den Hamburg hat geschrieben, du musst die Kosten der Option später mit bezahlen lassen.
Ja, genau.
Und das ist vielleicht auch, das funktioniert in der Analogie.
Also das Problem, was ich jetzt habe, ist, ich habe den Marco bei den Stahlrahmen dafür bezahlt, dass er mir diese Stahlrohre reserviert.
Wenn ich jetzt überhaupt gar keine Stahlräder baue, war das halt doof.
Und das ist im Code genauso.
Wenn ich den Marco jetzt irgendwie losschicke und sage, wir räumen das auf und ich ändere das in einem Jahr nicht, dann war es halt im Vergebens.
Aber so ist es halt.
Ich finde diese Metapher tatsächlich sehr schön.
Das ist für mich auch ein Haupt, ein Highlight von dem Buch.
Ich muss allerdings gestehen, dass ich da auch ein Problem habe.
Mir ist ehrlich gesagt nicht klar, warum das in diesem Buch auf dieser Ebene drin steht.
Ich würde erwarten, dass Entwickler in Eigenverantwortung Tidings machen, genauso wie ich von denen eigentlich erwarten würde, dass sie Refactoring in Eigenverantwortung machen.
Und ich hätte die Hoffnung, dass sie nicht gegenüber Management das begründen müssen.
Beziehungsweise ich kann mir auch nicht vorstellen, dass Management das auf dieser Ebene überwachen kann oder wird.
Selbst wenn Management sagt, das unterlässt ihr jetzt bitte, kann ich es wahrscheinlich weiterhin machen, weil ich mir nicht vorstellen kann, dass sich das Management Pull Requests anguckt und Commits anguckt und schaut, ob da keine Refactorings gemacht werden.
Das ist eine relativ absurde Situation.
Was ich allerdings schon mir vorstellen kann, ist, wenn man jetzt über eine Architekturmodernisierung spricht und sagt, wir müssen uns hinsetzen.
Das alte System ist am Ende seiner Lebenszeit.
Wir müssen wirklich viel Geld in die Hand nehmen, um das System zu ändern.
Dann ist so eine Optionsdiskussion schon hilfreich, weil dann kann ich sagen, wir müssen runtergehen, wir müssen weniger Features bauen, weil wenn wir jetzt weiter in dieser Geschwindigkeit Features bauen, dann machen wir uns die Optionen kaputt und dann haben wir in einem Jahr das Problem und haben dann überhaupt gar keine Möglichkeiten mehr.
Eigentlich würde ich behaupten, ist das eine gute Diskussion für größere, grobgranulare Änderungen und nicht für das, was jetzt in diesem Buch diskutiert wird.
Es soll ja noch Folgebücher geben.
Ich habe noch eine kleine Ergänzung gehabt.
Was ich auch interessant fand, war, dass er sagt, der Wert von so einer Option richtet sich danach, wie volatil der Markt ist.
Das heißt, so eine Option ist umso wertvoller, je weniger dir klar ist, wie sich der Markt weiterentwickeln wird.
Im Falle von Stahl, wie der Preis vielleicht steigen könnte, je weniger du darüber weißt, umso wichtiger oder wertvoller wird für dich diese Option.
Bei der Software ist es halt so, je weniger du darüber weißt, welche Features vielleicht später das sind, was deine Kunden wollen, umso wertvoller ist es für dich, diese Option zu schaffen.
Das fand ich auch noch eine ganz interessante Aussage.
Genau.
Das bedeutet, wenn ich in einem Umfeld bin, wo ein Product-Market-Fit für mich wichtig ist, wo ich noch nicht weiß, was die Kunden wollen, ist es vielleicht wichtig, eine saubere Code-Basis zu haben und darauf vorbereitet zu sein.
Das könnte man diskutieren.
Aber ich bin bei dir, dass es natürlich eine Schwierigkeit ist.
Warum muss man das überhaupt diskutieren mit dem Management?
Eigentlich ist es in der Verantwortung von Entwicklerinnen zu entscheiden, wann man etwas aufräumen muss.
Ich bin ja der Experte dafür und nicht das Management.
Zumindest auf dieser Ebene.
Ich muss gestehen, ich habe ganz viele Kunden, die sagen, ich habe ein Stück Legacy-Software und will viel Geld investieren, um das zu modifizieren.
Dafür ist diese Diskussion, glaube ich, total super.
Aber wäre ich ein Entwickler, würde ich sehr ungern in einer Umgebung arbeiten, wo ich Tidings so begründen muss.
Man muss noch dazu sagen, dass der gute Ward Cunningham den Begriff Technik-Adept überhaupt erst erfunden hat, weil er gegenüber Management-Refactoring begründen muss.
Das heißt, leider ist es so, dass wir in der Realität in diesem Problem sind.
Entwicklerinnen in dem Problem sind, das ist aber eigentlich unschön.
Ich habe nicht verstanden, dass das zwei alternative Erklärungsmöglichkeiten sind.
Zu sagen, ich benutze Technik-Adept oder ich benutze Optionen.
Ja, genau.
Ich glaube, Optionen sind da die bessere Möglichkeit.
Ich habe eine Episode gemacht zu Technik-Adept.
Da ist auch diese Geschichte mit Ward Cunningham drin und so weiter.
Es gibt ja noch eine andere Subtilität, die ich aber trotzdem loswerden wollen würde.
Ich habe vor einiger Zeit diese Episode gemacht zu dem Thema, können wir eigentlich die Entwickler in Produktivität messen?
Das geht zurück auf etwas, wo McKinsey gesagt hat, das können wir irgendwie.
Und wo der Kent unter anderem eine Kritik losgeworden ist.
Er hat letztendlich gesagt, sozusagen in einer groben Übersicht, dass wir eigentlich in einem Software-Projekt das ultimative Ziel Impact hat.
Zum Beispiel Umsatz, weil ich viele Kunden habe, viele Bestellungen.
Dahinter steckt, dass ich das richtige Feature implementiere.
Das sind Sachen, die nicht so wahnsinnig leicht zu messen sind.
Aber eigentlich müsste ich das als Produktivität messen.
Häufig ist es so, wenn ich anfange und ich messe erledigte Tickets, dann hilft mir das nichts.
Da können sinnlose Tickets sein.
Wichtig wären die Tickets, die tatsächlich Impact erzeugen.
Es ist so, dass er auf diesen Folien, ich hatte damals die Folien gezeigt, die der Kent geschrieben hat, und da war auch Heidi First referenziert, weil das anscheinend im Moment seine Webseite ist, auf der er ganz viel macht.
Was ich spannend fand, war, dass er nicht als ein Ergebnis eines Entwickler-Teams überhaupt erwähnt hat, dass es Optionen schafft.
Das fand ich ein bisschen schwierig.
Eigentlich müsste man jetzt sagen, wenn ich jetzt Impact generiere und dadurch mehr Umsatz generiere, das ist sicherlich ein Indikator dafür, dass ich was richtig mache.
Aber ich habe eigentlich auch diese langfristige Perspektive, wo ich jetzt eine Grundlage dafür geschaffen habe, dass ich in einem Jahr da auch sitze und ich habe etwas Nachhaltiges.
Das hat er nicht betrachtet.
Das finde ich schade, weil genau diese Mechanismen hat er zur Hand und könnte das jetzt nutzen.
Die Innocent Kitten bei Twitch hat geschrieben, die Schuldenbremse muss weg.
Damit haben wir das zweite politische Statement heute.
Was das jetzt so subsumiert für mich bedeutet, also ich würde behaupten, das sind Grundlagen.
Es ist, glaube ich, relativ einfach zu verstehen, wobei ich nicht sicher bin, ob man es aus dem Buch lernt.
Ich würde es eher durch Doing lernen, würde ich unterstellen.
Ich finde diese wirtschaftliche Betrachtung mit den Optionen total super.
Es sind wieder so ein paar Sachen drin, bei denen ich mir nicht sicher bin, ob sie belegt sind.
Wir haben das vorhin diskutiert an diesem Beispiel, sind kleinere Pull-Requests wirklich teurer und wie viel teurer sind sie eigentlich?
Wenn man ganz präzise ist, müsste man das mal empirisch untersuchen.
Das ist leider so ein Problem, das wir bei uns in der Industrie haben, dass wir das typischerweise nicht tun.
Aber nicht sei es drum.
Es ist nur allgemeines Gemäke.
Das Buch ist schwierig.
Insbesondere das, was wir beim letzten Mal diskutiert haben, ist sehr abstrakt.
Es gibt keine konkreten Code-Beispiele.
Das ist ein Problem.
Ich weiß nicht, was mit Tests ist.
Tests werden nicht ernsthaft diskutiert.
Lesbarkeit von Tests, Testabdeckung, solche Geschichten.
Ich glaube, dass das durchaus ein Buch ist, das sich Entwicklern ans Herz legen würde.
Die Kritik, die auch bei den Zuschauern gekommen ist, ist, der Neuigkeitswert ist so ein Medium.
Das finde ich nachvollziehbar.
Ich weiß nicht, wie du es siehst, Marco.
Das würde ich schon auch so sehen.
Das Neue war natürlich diese Betrachtung mit den Optionen.
Generell die etwas stärkere Theorie dahinter, das mal in der Ausführlichkeit zu diskutieren.
Das hat auf jeden Fall einen Neuigkeitswert.
Die Tidings, die er gesammelt hat, sind natürlich Dinge, die man in der Community kennt.
Aber da sehe ich wirklich den Wert, zu sagen, man schreibt das mal gezielt auf und hat einen Katalog von Dingen, der einfach zur Verfügung steht, den man sich anschauen kann.
Auch wenn jedes einzelne Tiding für sich genommen ist, ist natürlich nicht so viel Neuigkeitswert.
Das ist vielleicht auch so ein Punkt.
Patterns sind ja traditionell so, dass man sagt, die sind nicht deswegen toll, weil sich jemand krasse Gedanken gemacht hat, sondern deswegen, weil man es aus der Praxis abgeleitet hat, dem Ding einen Namen gegeben hat.
Dann soll es vielleicht auch kein Neuigkeitswert sein.
Das wäre vielleicht umgekehrt sogar ein Problem, wenn der Neuigkeitswert zu hoch wäre, weil dann hättest du vielleicht einen Teil, der noch gar nicht erprobt ist und man gar nicht weiß, ob es in der Praxis auch tatsächlich so funktioniert.
Hamburg hat gerade geschrieben, diese Kostenuntersuchung muss ja nicht öffentlich sein, aber eine Firma sollte für sich schon wissen, wie viel ein Release oder ein Feature oder ein Commit oder ein Fehler kostet.
Da sind jetzt verschiedene Sachen.
Da ist einmal diese Ebene mit dem Fehler.
Die Firma Crowdstrike kann bei einem bestimmten Fehler sehr genau sagen, wie viel der kostet.
Aber ich bin mir sonst nicht so sicher.
Das ist auch tatsächlich so, das ist auch etwas, was er im Buch schreibt.
Was hat er gesagt?
Die meisten Sachen sind reversibel.
Er hatte das Beispiel mit Steuerbescheiden.
Nicht, wenn ich falsche Steuerbescheide rausgeschickt habe oder eben das, was Crowdstrike passiert ist.
Von daher ist das schwierig.
Insbesondere ist es schwierig zu sagen, wie teuer Security-Fehler sind, weil die sind so lange kostenlos, wie sie nicht ausgenutzt werden.
Und der andere Punkt, und deswegen finde ich den Hinweis nochmal super.
Ich bin schon länger der Meinung, dass das mit den Kosten tatsächlich relativ einfach ist.
Wir haben alle Tagessätze.
Das heißt also, wenn ich weiß, wie lange es dauert, dann weiß ich, wie viel es kostet, weil ich den Tagessatz habe.
Gleichzeitig ist es aber auch so, dass das absurd ist, wie soll ich sagen, als Metrik, weil die Hoffnung ist, dass die Tagessätze, die wir nehmen, deutlich geringer sind, als der Wert, den wir generieren.
Und beim Wert wird es schwierig, weil die Frage ist jetzt, also nicht, ich sage jetzt dem lieben Marco, baue dieses Feature.
Wie viel ist dieses Feature wert?
Keine Ahnung.
Wird es vom Kunden angenommen, wird es nicht vom Kunden angenommen?
Schwierig.
Da einen Eurowert hinterzuschreiben, ist schwierig.
Ich glaube, es ist noch ein Tick schwieriger zu sagen, Marco räum doch bitte diesen Code auf, damit schaffe ich eine Option.
Aber die zu bewerten, ist glaube ich super schwierig, weil das hängt irgendwie davon ab.
Also nicht, dazu muss ich jetzt einmal sagen, wie sieht die Welt in einem Jahr aus, oder wann auch immer.
Und dann muss ich halt irgendwie außerdem sagen, welche konkreten Dinge werden sozusagen dadurch beeinflusst.
Und deswegen würde ich tatsächlich unterschreiben, das mit den Kosten ist wahrscheinlich gar nicht so schwierig.
Aber das mit dem Wert ist halt schwierig.
Und das finde ich halt auch doof, wobei ich das auch einschränken muss.
Also es ist ja durchaus so, dass wenn es so eine IT-Projektleitung, Programmmanagement gibt, dass die halt irgendwie sagen, wir bauen das jetzt und das kostet irgendwie N Euro und das bringt halt x Euro ein.
Also die rechnen Business Cases.
Und von daher gibt es das halt schon.
Es ist nur so, dass wir vielleicht auch als TechnikerInnen da zu wenig draufgucken.
Also das wäre vielleicht auch noch ein Thema da.
Genau.
Es gibt ja auch den Begriff des KPI-Driven Development.
Es gibt ja auch verschiedene Konzepte, wie man da arbeiten kann.
Brauchen wir jetzt nicht zu vertiefen.
Aber so ein Learning, was ich da mitgenommen habe aus der ganzen Thematik war, dass eine Metrik zu erheben, selber ja auch teuer sein kann.
Das heißt, man muss sich vorher auch überlegen, ist es einem auch das Wert, eine bestimmte Metrik überhaupt zu erheben?
Ja und vielleicht, genau das ist halt auch ein Punkt.
Ich glaube, die neue Estimates-Bewegung läuft ja auch in diese Richtung.
Nicht, dass man dann sagt, okay, also wenn ich ein Estimate mache, bedeutet das Aufwand.
Lass mich halt einfach das Feature bauen.
Und ich will das gar nicht bewerten.
Also ich glaube, dass Planbarkeit auch einen Wert hat.
Aber es bedeutet eben auch Aufwand.
Und von daher ist das eben auch nochmal ein wichtiger Hinweis.
Ich glaube, es ist als Erklärmodell hilfreich.
Also es ist glaube ich ein Erklärmodell, wo man irgendwie sagen kann, oder ich hätte eine größere Hoffnung, dass das etwas ist, was sozusagen im Management resoniert.
Weil sonst irgendwie total schwer zu erklären ist, warum wir jetzt nicht einfach nur Features kloppen die ganze Zeit.
Uns ist es glaube ich klar, dass man das nicht tun sollte.
Aber das irgendwie im Außenstehenden klar zu machen, das müssen wir glaube ich schon tun können.
Und da ist glaube ich das ein ganz guter Ansatz.
Gut, dann würde ich sagen, also mir bleibt noch übrig ein Hinweis auf die nächste Episode.
Das wird das Thema Firmenpolitik sein mit meinem Kollegen Michael Ahrens, einer der Geschäftsführer von SwagClub in der nächsten Woche.
Vielen Dank Marco, dass du da warst.
Ja, nochmal vielen Dank für die Einladung.
Es war eine sehr spannende Diskussion.
Immer wieder gerne.
Genau, wir haben gestern auch noch im Vorgespräch ganz viel über Technik diskutiert.
Die innocent kitten hat gerade noch geschrieben, aus Estimates werden Deadlines, je weiter die getragen werden.
Genau, das ist das nächste Thema.
Nicht Estimates sollten nur dazu dienen, um Entscheidungen zu fällen und Estimates sind keine Deadlines.
Vielleicht ist das auch noch ein Grund gegen Estimates.
Dann würde ich sagen, vielen Dank.
Schönes Wochenende und bis dahin würde ich sagen.
Bis dann.