Was ist Programmieren?

Sven: Hallo und herzlich willkommen bei einer neuen Folge des INNOQ Podcasts. Heute mit Daniel Westheide. Wir sprechen über das klassische Paper von Peter Naur, Programming as Theory Building und wie es dessen Inhalt in den letzten Jahrzehnten immer wieder in so interessante Diskussionen gebracht hat. Also sei es Agilität Anfang der 2000er, auch so aus dem Google Ads Team. 2015 und auch in einem Buch, Out of the Software Crisis, wurde das auch jetzt noch mal diskutiert. Also scheinbar hat der Peter Naur da was wichtiges zu sagen. Es geht darum, was Programmieren eigentlich ist und was es eigentlich für uns bedeutet. Also sei es das Problem zu verstehen, schnell und konsistent im Team zu arbeiten, Software wartbar zu halten und so weiter. Genau, darüber wollen wir quatschen. Mit Daniel. Daniel, herzlich willkommen. Stell dich doch mal kurz vor.

Daniel: Ja, hallo. Ja, ich bin Daniel. Ich bin Senior Consultant bei INNOQ seit 2013 dabei, also schon eine ganze Weile. Hab bisher auf dem Podcast hauptsächlich was zu funktionaler Programmierung gemacht, ein bisschen was zu nachhaltiger Webentwicklung und interessiere mich aber in letzter Zeit auch zusehends so für System Thinking und wie man das irgendwie in der Softwareentwicklung anwenden kann und so ein bisschen spielt dieses Paper da auch rein, wie man vielleicht nachher sehen kann. Und ja, freue mich jetzt darauf, mit dir mal über ein klassisches Paper aus den 80ern zu reden. Ja. Ja, ich habe mehrere Scala Bücher geschrieben, genau. Ja, genau.

Sven: Genau, genau. Hat bis heute überlebt. Okay, ja dann. Dann legen wir einfach mal los. Also der Peter Naur. Auf den sollten wir hören. Der hat einen Touring Award gewonnen. Und den kennen wahrscheinlich auch, also alle haben diesen Namen wahrscheinlich schon mal gehört, die Informatik studiert haben, weil der ist ja Teil von dieser Backus Naur Form. Was ist nochmal die Backus Naur Form?

Daniel: Genau. Ja, es ist eine formale Sprache zur Darstellung kontextfreier Grammatiken und ich glaube, das kam bei mir auch in einer der ersten Vorlesungen dann vor, weil man damit ja auch alte, die Grammatiken von Programmiersprachen wie Java oder so auch dann eben darstellen kann ganz gut. Also es glaubt, wenn man Informatik studiert hat, hat man das schon zu Beginn des Studiums mal gesehen. Irgendetwas, was mit Backus Naur Form gemacht wurde.

Sven: Genau, also ich kann mich noch erinnern, bei mir hat es tatsächlich auch mit C-Programmierung angefangen. Ich weiß auch gar nicht, ist die BNF, war die auch nicht sogar in diesem Kernigan-Ritchie-Buch direkt am Anfang drin? Also man konnte dem gar nicht so richtig entkommen, aber naja.

Daniel: Das weiß ich gerade nicht. Ja, aber interessant, das ist ja eine sehr formale Angelegenheit und dieses Paper hat ja schon fast was Philosophisches, über das wir heute reden. Es ist irgendwie eine ganz andere Richtung eigentlich. Ja. Um was geht es eigentlich in dem Paper so grob? Also erstmal vielleicht zur Motivation des Papers, was er da so sagt. Es geht darum, ein besseres Verständnis zu ermöglichen von Modifikationen von Programmen. Das ist zumindest so seine Hauptmotivation gewesen. Er stellt wahrscheinlich zur damaligen Zeit ein neues Verständnis von Programmieren vor, was dem damaligen Mainstream von Programmieren als Textproduktion, also Produktion von Source Code und Dokumentation gegenübergestellt wird, weil das eben bestimmte Dinge nicht erklären kann, die mit der Modifikation von Programmen zusammenhängen. Und er sagt eben, das Programmieren eben nicht alleine daran besteht, Texte zu produzieren, also Source Code und Dokumentation, sondern dass es darum geht, eine Theorie zu bilden von dem Programm. Und was das genau bedeutet, das müssen wir vielleicht nochmal erklären. Es geht also darum, ein tiefes Verständnis der Zusammenhänge zwischen dem Programm und der realen Welt zu entwickeln. Oder einen Teil der realen Welt, auf das sich das Programm bezieht. Wir würden wahrscheinlich heute sagen der Domäne. Und jemand, eine Person, die diese Theorie besitzt, ist dann eben auch in der Lage, diese Zusammenhänge zu erklären. Sie kann erklären, warum das Programm so ist, wie es ist, also den Code quasi rechtfertigen. Und eben am wichtigsten fast, sie kann konstruktiv auf Anforderungen reagieren, das Programm anzupassen an Änderungen der Fachlichkeit. Also Peter Naue sagt, Source Code ist eigentlich verlustbehaftete Repräsentation des Programms, weil ganz viel eben in den Köpfen der Leute steckt, die dieses Programm geschrieben haben. Die besitzen die Theorie.

Sven: Ja, machen wir mal so eins nach dem anderen. Also was in den Köpfen steckt ist natürlich, es hat natürlich viel auch mit so Team, mit Fluktuation im Team und so weiter zu tun und wie Wissen verteilt wird. Machen wir, würde ich sagen, in ein paar Minuten. Starten wir mal mit der ersten Aussage. Programmieren ist nicht einfach das Schreiben von Codes, Produzieren von Text. Wir haben ja auch oder du hast so eine kleine Umfrage unter unseren Kollegen gemacht. Hast die gefragt, was ist denn eigentlich Programmieren? Was kam denn da raus?

Daniel: Genau, ja, das haben wir natürlich gefragt, weil wir mal wissen wollten, wie verbreitet diese Ansicht, die Peter Nau in dem Paper beschreibt, eigentlich so ist. Und wir haben auch gefragt, ob die Leute, die Informatik studiert haben, eigentlich im Studium gelernt haben, was Programmieren ist, ob das da thematisiert wurde und wenn ja, was da ihnen vermittelt wurde. Also es gibt viele Aussagen dazu, dass Computer programmieren ist, ihnen mitzuteilen, was sie tun sollen, auf eine Weise, dass die Anweisungen automatisch wiederholbar sind. Ausarbeiten, Niederschreiben einer formalen Beschreibung eines Algorithmus, so dass er automatisch abgearbeitet werden kann. Etwas automatisieren im Allgemeinen, was eben interessant ist. Es wurde manchmal genannt, automatisieren geht auch ohne Computer. Und zwei Kollegen haben geantwortet, dass sie das nicht nur im Kontext von IT-Verwenden programmieren, sondern auch quasi Menschen oder sich selbst programmieren durch logische und klar definierte Abläufe und Reaktionen auf Verhalten, wie man dazu bringen in einem bestimmten Schema zu reagieren. Aber auch das geht natürlich nicht in die Richtung von dem, was Naur sagt. Also die Äußerung, es war keine Äußerung dabei, die irgendwie diesen Aspekt der Theoriebildung erwähnt oder zumindest umschrieben hat. Und interessanterweise haben die meisten auch entweder vergessen, ob das im Informatikstudium vorkam oder sagen, es wurde dann nicht vermittelt, was Programmieren ist. Es wurde vermittelt, was ein Algorithmus ist, kam einmal vor und daraus hat die Person abgeleitet. Dann ist Programmieren wohl etwas, was mit dem Schreiben von Algorithmen zu tun hat. Vielleicht war die Frage nicht ganz so toll. Vielleicht hätte man fragen müssen, was ist Softwareentwicklung? Und die Leute verstehen unter Programmieren wirklich nur das, was mit der Tastatur und dem Schreiben zusammenhängt. Das weiß ich nicht.

Sven: Ja, ich habe auch drüber nachgedacht. Also ich habe jetzt geantwortet, weil ich wollte mich da sozusagen nicht einmischen, aber ich konnte mich auch nur daran erinnern, wir hatten auf jeden Fall so ein Buch gehabt von Peter Reschenberg oder so, “was ist Programmieren”? Und ich weiß, dass ich das gelesen habe, dass jetzt da irgendwie Modellbildung oder wie auch immer dazu gehört, daran konnte ich mich auch nicht erinnern. Als du dieses Paper erwähnt hast, da ist mir, da habe ich so eine Erinnerung gehabt an die GOTO Berlin, also eine Konferenz vor acht Jahren oder so und wir hatten mal den George Fairbanks eingeladen. George Fairbanks, er hat ein Buch geschrieben auf Softwarearchitektur. Just Enough Softwarearchitektur ist ganz interessant. Und er ist jetzt seit, keine Ahnung, zehn Jahren bei Google in diesem Google Ads Team oder Ads Exchange, wie das immer heißt. Und ich kann mich erinnern, sein Vortrag, der war irgendwie sowas, können wir in die Show Notes packen, der war sowas in die Richtung Model Building, oder auch so Model Theory überprogrammieren oder so was. Und dann habe ich gedacht, ich muss den Vortrag noch mal angucken. Vielleicht wird da Peter Naur zitiert. Und natürlich zitiert er da Peter Naur und geht genau darauf ein, weil er ja so, er regt sich so ein bisschen. Aufregend ist zu viel. Aber er sagt halt, na ja, es ist halt einfach nicht, dass stupide Also stupide ist vielleicht auch wieder zu hart, aber er sagt, Programmieren ist halt nicht einfach nur Textproduktion, sondern wir müssen wirklich dieses, wir müssen mehr Modelle bilden, wir müssen das Problem verstehen. Und früher hatten wir das relativ oft gemacht, sagt er, da haben wir noch hier so viel objektorientierte Analyse gemacht. Und heutzutage, da kommt irgendwie eine Anforderung rein. Und dann setzen wir die um, dann kommt die nächste rein, dann setzen wir die um, dann kommt die nächste rein. Irgendwann wird mal ein bisschen Refaktort und das kann dir wohl nicht gewesen sein. Und dann habe ich auch gedacht, ja, das stimmt eigentlich. Früher gab es immer noch diese Methoden.

Daniel: Ja, also essentiell ist natürlich auch Aber heute gibt es ja auch Methoden und wir machen die ja auch. Was würdest du so sagen? Was sind so aus deiner Sicht gute Methodiken, um so ein Modell von der Welt zu erstellen? Also um die Probleme bestmöglich zu verstehen. Mit den entsprechenden Fachleuten zu reden und die besten Falle auch ins Team zu integrieren. Die strategischen Patterns vom Domain Driven Design helfen da sicherlich auch so. Sachen wie Event Storming, das ganze Ziel von Domain Driven Design ist ja eigentlich, ein tiefes Verständnis zu gewinnen. Das wird, glaube ich, so fast wörtlich auch irgendwo gesagt in einem der Bücher. Das passt da also auf jeden Fall sehr gut. Auch Prototyping finde ich eigentlich ein gutes Mittel dann, um auch ein Problem zu durchdringen, weil es geht ja nicht nur um das Verständnis der realen Welt, sondern auch darum, um die Beziehung zum Code und vielleicht muss man sich da auch erstmal ein bisschen ausprobieren, bevor man dann anfängt, die tatsächliche Lösung zu bauen.

Sven: Genau, ja. Also zum Event Storming, da sagt der Alberto Brandolini, der sagt irgendwie, es ist nicht so, dass wir, wir setzen nicht das um, es wird nicht das umgesetzt, was die Domain-Experten wollen, sondern wir setzen das um, was wir glauben, was die Domain-Experten wollen. Und es ist natürlich am besten, da so nah wie möglich ranzukommen. Ja, das stimmt. Prototyping finde ich eigentlich auch ganz, ganz interessant, was du sagst, weil wir hatten mal, also ich hatte schon zweimal die Erfahrung gehabt, dass Leute sich einfach irgendwie ewig lang überlegen, wie sie es machen. Und dann fangen sie an und dann stellt sich raus, das funktioniert halt überhaupt gar nicht so. Das ist dann ein bisschen peinlich gewesen, aber die wollten auch nicht hören. Na ja. Ja. Ja, und mit Fachleuten reden, die sie ins Team integrieren. Also ich bin ja so alter Extreme Programming Fan. Da war das ja früher schon so gewesen, dass man gesagt hat, Customer on site. Also es muss natürlich nicht direkt der Kunde sein, sondern in aller Regel auch jemand, der den Kunden repräsentiert. Und das fand ich natürlich auch super, weil du hast halt direkt diese Konversation, worum geht es denn eigentlich, ich habe das jetzt nicht richtig verstanden. Und dann, ja, tut sich eine ganz, ganz neue Welt auf, sozusagen, wenn man mit den Leuten mal wirklich über die, über die Probleme, die sie haben, diskutieren. Ja, wir hatten, fällt mir gerade noch so ein, wir hatten noch mal den Fall, dass wir, dass wir einfach uns zu den Leuten dazusetzen und die bei der Arbeit beobachten und dann mit denen diskutieren. Warum machst du das? Warum klickst du so?

Daniel: Das ist ein wichtiger Punkt. Das habe ich selber bisher, glaube ich, nur ein einmal gemacht, aber das war super wertvoll. Also Beobachtung quasi der Nutzer des Systems, das wir bauen. Welche Probleme haben die und wie sieht die Fachlichkeit eigentlich genau wirklich aus? Kann man dadurch sehr gut mitbekommen, finde ich.

Sven: Also so sollte man es tun. Wie ist so dein Eindruck? Was machen wir jetzt als INNOQ in unseren Projekten gut oder auch schlecht, um dieses tiefe Verständnis zu verankern?

Daniel: Also die Techniken, die ich eben aufgeführt habe, die nutzen wir natürlich viel so. Das machen wir also dann wohl gut. Aber auch darüber hinaus, was wir meiner Meinung nach gut machen, ist in der Regel zumindest in den Projekten, die ich jetzt hatte, dass wir eben neue Teammitglieder nicht einfach alleine loslaufen lassen, indem man ihnen die Dokumentation gibt. Und dann sollen sie halt mal machen. Kann ja eigentlich nicht funktionieren, weil wir ja gehört haben, dass der Code und die Dokumentation verlustbehaftete Repräsentationen sind. Was wichtig ist, was vielleicht manchmal nicht gut läuft, die Fachseite vom Kunden, die muss natürlich auch irgendwie zur Verfügung stehen, wenn man sie einbeziehen möchte oder durch Vertretung. Es hilft halt nicht, wenn ein Kunde seinen Fachpersonal halt möglichst wenig von uns behelligt haben möchte. Wir sollen einfach mal machen und müssen dann raten, was die Leute wirklich für Probleme haben. Das ist dann nicht gut.

Sven: Man nicht so viel quatschen, sondern einfach machen hört sich irgendwie immer gut an, aber eigentlich man muss auch ein bisschen quatschen, um es zu verstehen. Wir hatten auch noch, also in der Vorabbesprechung haben wir noch so diskutiert, was machen denn eigentlich andere Leute, um ein tieferes Verständnis von den Problemen zu bekommen. Und das fand ich eigentlich eine ziemlich interessante Diskussion. Du hast auch den Rich Hickey genannt, also der Mann hinter Clojure und der Datomic. Now, hammock-driven development. Was ist hammock-driven development?

Daniel: Ja, Hammock Driven Development war auch, glaube ich, ein Vortrag von ihm einmal vor mittlerweile vielen Jahren. Eigentlich sagt er auch, dass wir halt mehr Zeit damit verbringen sollten, über die Probleme nachzudenken und sie zu verstehen, anstatt einfach nur Features zu entwickeln. Und indem wir halt darüber nachdenken, am besten in der Hängematte, anstatt vor dem Rechner, sind wir dann besser in der Lage, eben tatsächlich gute Lösungen auch zu designen, anstatt dass wir einfach loslegen mit dem Coden.

Sven: Ja, also die erinnert mich so ein bisschen an so einen Arbeitskollegen von früher, der hatte, der ist schon sehr alt und er hat also seine Doktorarbeit geschrieben hat, da musste er ja noch so, da musste er noch so Tests machen, meinte er auch, also er hat irgendwie so x Stunden Zeit gehabt und bis x-1-Stunde hat er noch überhaupt nicht an der Lösung gearbeitet, weil ihm das Problem noch gar nicht so klar war. Und er muss die ganze Zeit, er muss sich entspannen und muss verstehen, was das Problem ist. Und weil es macht halt überhaupt keinen Sinn, loszulegen, wenn man nicht so genau weiß, um was es geht. was man tun soll. Es kam irgendwie heute ein ganz interessanter Podcast raus, den würde ich auch mal verlinken mit Kelsey Hightower. Also Kelsey Hightower ist so ehemaliger Distinguished Engineer bei Google, ziemlich bekannt, was so Kubernetes angeht. Und er hat in dem Podcast auch gesagt, wir müssen einfach trennen von, wir müssen Impact und Aktivität trennen. Wir sind irgendwie zu sehr in diesem Aktivitätenmodus, dass wir halt so Dinge tun, wir implementieren Features Und da ist auch alles schön und gut, wir implementieren die Sachen so gut wie wir können, aber wir müssen halt viel besser verstehen, was machen wir denn da überhaupt? Also was wollen wir denn für sozusagen mit diesem Feature oder mit dieser Sammlung an Dingen denn für einen Impact sozusagen in der Welt erledigen? Für wen machen wir das? Und er meinte so, das ist eigentlich, hört sich jetzt so banal an, aber das ist ein riesen, riesen Unterschied. Wo ich einfach nur sage, ja, gib her, ich mach’s und ich mach’s so gut, wie es geht. Ich bin der beste Jenkins Pipeline, wie auch immer, oder sowas. Implemente oder ob ich wirklich verstehe, was machen wir denn hier überhaupt? Aber vielleicht noch so zum Abschluss. Jetzt so dieses drüber nachdenken tiefes verständnis das hat doch so ein bisschen was von big design upfront oder oder nicht also das ist ja sozusagen der feind der agilität

Daniel: Ja, zumindest wird das oft so gesagt von manchen Leuten. Aber ich würde behaupten, dass solche Leute weder Agilität und Extreme Programming richtig verstanden haben, noch die anderen Ansätze. Es wird, glaube ich, ein sehr großer Gegensatz aufgemacht, der so nicht unbedingt existiert. Nur wenn man es sehr zuspitzt und vielleicht das nicht so umsetzt, wie es gedacht war.

Sven: Also ich muss sagen, damals habe ich auch so ein bisschen dran geglaubt, also als jetzt so Agiles Manifest und so weiter kam, die haben zwar gesagt Simple Design, aber es gab auch so Leute wie Ron Jeffreys, also vielleicht tue ich dem jetzt irgendwie unrecht, aber ich kann mich halt erinnern, dass der halt sagt, fangen an zu programmieren, was soll das Ganze, ist alles Blödsinn. Aber ich glaube, er war vielleicht einfach, er wollte wahrscheinlich einfach nur so ein bisschen Stress machen sozusagen und die Leute zum Nachdenken anregen, weil ja, Martin Fowler hat ja auch so ein Artikel geschrieben, ist Design Dead vor 20 Jahren. Und da sagte er auch, also Es ist ein riesen Unterschied zwischen Big Design Up Front und einfach mal loslegen. Also ein bisschen nachdenken hat noch niemandem geschadet. Gut. Ja, ich würde vielleicht noch mal auf einen weiteren Punkt, also weiterziehen. Und zwar So ein anderer Punkt in dem Paper, du hast ja auch eben glaub ich erwähnt, ist die, du hast gesagt, das eigentliche Produkt der Softwareentwicklung ist nicht der Code selbst, sondern irgendwie das Verständnis über den Code. Und da sagt er halt, okay, so Wissensweitergabe und Theoriebildung hat eine große Bedeutung. Und gab’s eigentlich zu der Wissensweitergabe irgendwas von unseren Kollegen? Haben die dazu was gesagt? Ja.

Daniel: Nee, leider nicht. Aber vielleicht lag es halt irgendwie in der Fragestellung. Also, dass man überhaupt in einem Team ist. Der Gedanke wurde ja gar nicht geäußert in den Antworten. Und ich glaube immer noch, dass es daran liegt, dass wir Programmieren und nicht Softwareentwicklung gesagt haben. Aber das Paper heißt nun mal Programming, nicht Software Development.

Sven: Ich fand es auch interessant, weil wir machen eigentlich ziemlich viel, um Wissensweitergabe zu machen. Aber vielleicht bevor wir dazu kommen, ich fand es ganz interessant, du hast den Bal

ldur, also im Vorabgespräch den Balldur Pjörnsinsen oder Pjartnarsson genau zitiert. Und der fragt sich halt, wenn man das ernst nimmt, was bedeutet das eigentlich für die für die Fluktuation? Also wie wichtig ist es, dass irgendwie, dass irgendwie Leute gehalten werden?

Daniel: Wie hat man das so? Ja. Genau. Eigentlich kommt das ja sogar andersweise schon in dem Paper vor. Ich glaube, Peter Naur schreibt dazu was gegen Ende auch, dass die Konsequenz aus dem, was er sagt, dass Programming Theory-Bildung ist, bedeutet eigentlich, dass man die EntwicklerInnen eigentlich in einer permanenten Rolle haben möchte, dass sie nicht irgendwie kurz kommen und dann wieder gehen. Und das führt dann der Baldur halt nochmal weiter. Sind halt keine austauschbaren Ressourcen, die einfach Text produzieren. Nein, einfach…

Sven: Was? Was? Moment mal, nee. Du bist eine Ressource, du bist eingeplant als eine Ressource und wenn du die Schippe Sand von links nach rechts schaufelst, dann kann das ja auch der nächste machen.

Daniel: Genau, aber das ist ja erstaunlich, dass diese Ansicht jetzt heute immer noch relativ verbreitet ist. Ich meine, das wurde auch schon in Peopleware beschrieben, dass das ein Problem ist, diese Ansicht unter Managern. Und das ist nun auch schon ziemlich alt. Genau.

Sven: ja das ganze ist auch schon ende der 80er oder wann kam people where

Daniel: Ich bin mir nicht ganz sicher. Ich habe, glaube ich, eine spätere Auflage gelesen. Die war, glaube ich, aber aus den 90ern. Ich weiß nicht genau. Aber es ist auf jeden Fall schon eine Weile her. Ja, Baldur beschreibt halt so die Idee von First- und Second-Generation Programmers in einem Team. Und er sagt halt die erste Generation, das sind halt die, die haben die Theorie, Die haben die Theorie wahrscheinlich auch gebaut, als die Software entwickelt wurde. Und Second Generation wären dann diejenigen, die dazu kommen und dann aber von den aus der ersten Generation eigentlich die Theorie lernen müssen oder übernehmen müssen quasi. Und das passiert natürlich eben nicht einfach durch Dokumentation lesen. sondern indem sie, dazu sage ich geNaur auch was, dass sie eigentlich begleitet von denjenigen, die schon da waren, halt wirklich Aufgaben übernehmen, mit dem Code arbeiten und da ihr Verständnis entwickeln unter Aufsicht. Und wichtig ist eben, Also Second Generation Programmers werden irgendwann auch zu First Generation Programmers, wenn sie das tiefe Verständnis entwickelt haben. Und du hattest ja zur Fluktuation eigentlich jetzt gefragt. Da ist dann halt natürlich das Problem, wenn ich zu schnell Leute verliere, dann habe ich vielleicht nur noch Second Generation Programmers, die das Verständnis noch nicht entwickelt haben. Oder noch nicht mal Second Generation.

Sven: Und deswegen ist es halt schon sehr wichtig, Leute zu halten. Wir haben ja jetzt in den letzten Jahren immer wieder gerade bei Bei Start-ups, die von großen Investoren halt gebacked waren, gesehen, wenn dann gerade das Geld aus war, dann gab es halt eine Kündigungswelle. Dann hat man irgendwie 30 Prozent der Belegschaft entlassen. Und ein halbes Jahr später oder so war plötzlich wieder Geld da. Dann wurden Leute eingestellt. Und das geht halt ja eigentlich mit einem riesigen Wissensverlust einher. Die Theorie in den Köpfen geht ja weg und damit ist eigentlich auch nach Piter Nauber das Programm tot. Wenn niemand mehr im Team ist, der die Theorie hat, sagt er, ist das Programm tot. Es kann nur noch ausgeführt werden, aber nicht mehr verändert werden. Und im schlimmsten Fall muss ich dann neu schreiben, um mir selber eine neue Theorie zu bauen.

Sven: Ja, also das, dass das Programm tot ist, das hatte ich auch mal in so einem meiner ersten Jobs erlebt. Das fand ich auch ziemlich grausam. Also da gab es, wir hatten eine Software geschrieben. Da waren 30 Leute oder so involviert und über Jahre. Also war einfach keine Ahnung, fünf, sechs, sieben, acht Jahre. Und dann wurde unser Kunde wurde aufgekauft. Und die haben halt gesagt, also der neue Besitzer hat gesagt, ja, wir haben einen anderen, wir haben so einen anderen Dienstleister und wir werfen euch jetzt raus und der andere Dienstleister, der übernimmt das jetzt einfach. Und dann hat der andere Dienstleister übernommen und ein Jahr später, ein Jahr später haben die uns nochmal kontaktiert und haben gesagt, wir waren jetzt noch nicht in der Lage, irgendwie das Ding zu deployen und so und wir bräuchten, wir bräuchten ja noch ein paar Leute, die mit uns an der Software arbeiten. Und ja, das fand ich schon ganz schön heftig, dass irgendwie so ein Jahr die Leute beschäftigt und du bist kein Millimeter vorwärts gekommen, weil du kannst ja auch nicht einfach so was neu schreiben. Also wenn das Programm tot ist, dass irgendwie seit das von 30 Leuten fünf Jahre entwickelt wurde, brauchst du ja auch wieder 30 Leute um fünf Jahre, um das neu zu schreiben. Das will man nicht unbedingt.

Daniel: Genau. Ja, das ist auch das interessante an diesem Verständnis von Programmieren als Theory Building im Gegensatz zur Textproduktion, dass eben Änderungen nicht so trivial sind oder Anpassungen des Programms. Man muss die Theorie kennen. Und wenn Programmieren Textproduktion ist, dann hätte ich ja für einen Änderungswunsch beliebig viele Lösungen, die alle in Ordnung sind. Und wenn Programmierend Theoriebildung ist, dann gibt es eigentlich nur ein oder sehr wenige richtige Lösungen, die nämlich konsistent sind mit der Theorie. Also auch mit den Metaphern und Patterns, die man in diesem Programm benutzt. Und ich kann es eben auch falsch machen. Und dann habe ich nachher wirklich ein Programm, was überhaupt keinen einheitlichen Stil mehr hat, wo man nicht mehr erkennen kann, was man sich dabei gedacht hat. Man hat irgendwie zig verschiedene Ansätze. von verschiedenen Leuten.

Sven: Ja, genau, also man könnte natürlich, also ich könnte jetzt dagegen setzen und sagen, ja, ich mache die Änderung und der Test bleibt grün und dann ist ja eigentlich alles in Ordnung, ja, aber dem ist nicht so. Ja, ich habe mich früher, habe ich mich immer so ein bisschen gewundert, dass ich, ich habe halt meine Sachen entwickelt. Und dann kam dann der Lead Developer und hat gesagt, so kannst du das nicht machen. Ja, nicht so doch. Also ich meine, funktioniert ja. Ja, aber So funktioniert unsere Software nicht. Du kannst das eigentlich nur so und so und so machen, im Grunde genommen das, was du sagst. Und es hat schon ein bisschen gedauert, dass ich dachte, ach so, ja, stimmt. Wir wollen ja, dass alles gleich bleibt. Fred Brooks hat, glaube ich, auch dieses Buch The Design of Designs geschrieben. Er sagte ja auch, also erfolgreiche Designs, egal ob der Software ist oder nicht, die haben so eine konzeptionelle Integrität. Das ist ein wichtiges Merkmal von erfolgreichen Entwürfen.

Daniel: Ja. Es kam ja auch in dem Paper vor, da hat ja Peter aber auch ein Beispiel genannt, wo, glaube ich, ein Team hat irgendwie so den Source Code eines anderen übernommen, um einen Compiler an eine andere Programmiersprache anzupassen. Und da war dann auch irgendwie nach einem Jahr oder so die Theorie, die dahinter stand, konnte man nichts mehr von wiedererkennen.

Sven: Ja, das ist auch so ein Problem, das wir in unseren Projekten haben. Also, ich meine, wir machen halt was für Kunden und dann, wir wollen das nicht und der Kunde will das ja auch nicht, ewig sozusagen von uns abhängig sein und wir wollen nicht von dem Kunden, so ungefähr. Wie, was würdest du sagen, wie macht man idealerweise so eine eine Übergabe von der Theoriebildung, wenn man so eine Consultancy ist. Also eine Übergabe ist ja irgendwie doof. Der Tod.

Daniel: Ja, eine Übergabe funktioniert eigentlich nicht. Das wäre dann auch, wenn Peter Naur Recht hat, könnte man das so sagen. Wichtig wäre also, dass man interne ProgrammiererInnen nach und nach ins Boot holt. und eigentlich langsam die Consultants halt herausholt nach und nach. Natürlich nicht eben nicht alles auf einen Schlag, sondern genug Zeit bleibt, damit eben aus Second Generation internen, irgendwann First Generation interne werden können und dann die externen gar nicht mehr gebraucht werden. Aber auch Innerhalb eines externen Entwicklungsteams ist es natürlich dann auch wichtig, nicht zu oft zu rotieren. Nur weil man vielleicht keine Lust mehr hat. Nach drei Monaten sollte man nun wahrscheinlich nicht ein Projekt verlassen.

Sven: Da habe ich auch so mehrere Erlebnisse gehabt, was angeht. Also ein Kunde von mir zum Beispiel hat gesagt, du musst zwei Jahre bleiben. Weil alles unter zwei Jahren, das bringt irgendwie nichts. Am liebsten noch länger. Also einfach weil du brauchst so lange, um irgendwie dieses System zu verstehen. Und wir müssen ja auch in dich investieren. Und da muss ich einfach auszahlen. Da musst du einfach musst du halt hier bleiben. Und, ähm, du musst, also die hatten gesagt, okay, du musst hier immer, wir müssen immer pairen, ja, wir haben weniger Developer Work Stations als Entwickler und so weiter, und dann musst du ja noch mal überlegen, ob du dann bei uns bleiben willst. Fand ich immer ganz, ganz coole Zeit bei denen, ja. Hat auch irgendwie Sinn gemacht. Und, ja, ich hab’s grad genannt, wir haben ziemlich viel gepaert. Was hältst du davon? Also Pairing, Mobbing, Ensemble Programming?

Daniel: Ja, ich habe beides schon gemacht. Pairing und Ensemble Programming. Ich glaube, wir haben es damals noch Mob Programming genannt. Gehen wir ja jetzt eher von weg von dem Begriff. Ich fand das damals schon sehr gut. Da hatte ich dieses Paper aber nicht so im Kopf. Und wenn man jetzt nochmal so drüber nachdenkt, nachdem man das gelesen hat, lässt sich das auch gut erklären, finde ich, weil eben Es ist ja wichtig, dass nicht nur ich eine Theorie entwickle und jemand anders entwickelt vielleicht eine andere Theorie. Also wir wollen ja die gleiche Theorie von dem Programm haben im Team, damit wir eben dieser konzeptionelle Integrität auch wahren können. Und das ist halt immer gegeben, wenn alle Änderungen immer zusammen von allen gemacht werden. Dann ist auch die Theorie im Grunde gleich bei allen im Kopf. Zumindest ist die Chance viel größer, dass man da nicht irgendwelche Missverständnisse entwickelt.

Sven: Ja, also ich habe jetzt noch nie Ensemble-Programmierung gemacht. Ich bin ja so alter Pärer. Kannst du vielleicht noch mal ganz kurz sagen, wie das funktioniert für Leute wie mich?

Daniel: Ja, so ganz, ganz grob könnte man sagen, dass es im Grunde halt so ähnlich ist wie Pairing, aber mit mehr als zwei Leuten. Also im Idealfall mit dem gesamten Team sitzt man vor einem Rechner, eine Person ist dann der Typeist oder die Typeistin und die anderen dürfen halt sagen, was diese Person an der Tastatur tippen soll. Die Person an der Tastatur darf aber eben nur tippen und nicht selber Ideen einbringen und dann rotiert man aber alle x Minuten diese Rolle.

Sven: Okay, okay. Ja, ich muss unbedingt mal machen. Also wir hatten halt mit rotierenden Pairs mal rum experimentiert, das fand ich zum Beispiel, das fand ich irgendwie nicht so gut wie feste Pairs, weil

Daniel: Hmm. Ja.

Sven: Ja, klar, also für Theorie-Building jetzt mit dem Paper im Hinterkopf würde ich vielleicht anders drüber nachdenken, aber es war halt schon sehr, sehr, sehr, sehr anstrengend und es hat alles sehr, sehr, sehr, sehr lange gedauert. Und da sehe ich vielleicht auch den Vorteil vom Ensemble Programming, wenn alle das zusammen machen, dann haben alle zusammen die Chance, die Theorie, das Modell zu erarbeiten. Bei den rotierenden Pairs ist natürlich so, wenn du sozusagen der bist, der immer dabei ist, dann hast du natürlich

Daniel: Ja. Ja, genau. Und im Ensemble hatte ich auch die Erfahrung, irgendjemand ist dann auch immer der weiter darauf achtet, dass du eben konsistent mit der Theorie bist mit der gemeinsamen, dass man nicht. Du kannst es ja auch durch ein Code Review theoretisch alles sicherstellen, aber es ist halt schon effizienter, einfach das direkt beim Coding schon sicherzustellen. Zumindest meine Erfahrung.

Sven: Ja, Pairing als oder Ensemble Programming als Art der Wissenswiedergabe. Ja, ich glaube, das wird einfach zu sehr unterschätzt. Da gibt es immer so diese Sprüche. Ja, das kostet viel zu viel und so weiter, aber. hat auf jeden Fall ziemlich große Vorteile. Und ich hätte auch gesagt, man ist auch, also was heißt ich sage das, aber Alistair Cockburn, der hat ja auch mal gesagt, also Alistair Coburn vielleicht zur Erinnerung, der hat ja auch beim Agile Manifest mitgemacht, der hat ein Buch geschrieben, Agile Softwareentwicklung. Da hat er übrigens auch dieses Paper zitiert, also er hat das nicht nur zitiert von Peter Naur, der hat es ja komplett abgedruckt und noch mal seine Meinung dazu gesagt. Er hat auch gesagt, Dadurch, dass wir Pairing machen und versuchen, ein gemeinsames Modell zu haben, werden wir natürlich, also diese Arbeit, die zahlt sich aus. Wir sind einfach viel schneller. Man ist viel schneller, wenn zehn Leute im Team eine gemeinsame Theorie im Kopf haben und in eine Richtung programmieren oder dass man halt zehn Leute hat, die halt unabhängig voneinander irgendwas runter tippen.

Daniel: Ja. Ja, und das Risiko ist ja auch weniger gering. Also zum einen können Leute mal in den Urlaub gehen, ohne dass das Team ausgebremst wird. Und es ist auch nicht so schlimm, wenn tatsächlich dann einer im Team zum Beispiel entscheidet, die Firma zu verlassen und dann ausscheidet.

Sven: Ja, genau, genau. Also ich fand jetzt in diesem einen Projekt, wo wir dieses viele Pairing gemacht haben, das fand ich ganz interessant, weil die haben gesagt, also idealerweise machst du sechs Wochen Urlaub im Sommer. So viel Urlaub habe ich leider nicht, weil ich muss ja noch anderweitig machen. Warum eigentlich sechs Wochen? Dann meinten die, naja, damit wir die Lücken sehen. Also Sachen, die nur du kannst, das wollen wir nicht. Es war aber nicht so, dass jeder alles machen sollte, aber es soll zumindest eine größere Gruppe geben. Ja. Ja, so eine Notiz habe ich mir noch zur Fluktuation gemacht. Und zwar ein Kunde von uns. Das fand ich halt ziemlich interessant. Und so im Nachhinein, jetzt wo wir auch nochmal über dieses Paper reflektiert haben, ziemlich clever. Da gab es die Corona-Krise. Und dann wurde sozusagen alles erstmal auf Halt gesetzt. Also war so die Idee, aber die haben halt gesagt, na ja, wir müssen die Externen weiter engagieren, die von Anfang an dabei waren. Also ist ja irgendwie was einfaches zu sagen, alle Externen raus. Dann haben die gesagt, nee, das können wir nicht tun, weil die, wenn wir die rauskegeln, dann sind die dann irgendwie in einem anderen Projekt und dann bei uns geht es ja auch irgendwann mal wieder weiter. Und die haben halt das Wissen. Die haben sozusagen diese Theorie, wie das System funktioniert. Und wenn die weg sind, dann… Irgendeiner muss dann allen anderen, die neu sind, muss das wieder erklärt werden. Deswegen versuchen wir eigentlich alle zu halten, die dabei waren. Das fand ich eigentlich… Also am Anfang hab ich gedacht, das ist aber abgefahren. Aber so im Nachhinein denke ich, eigentlich alles andere wäre doof gewesen.

Daniel: Ja.

Sven: Gut, ich würde mal weiterziehen zur Dokumentation. Also Dokumentation und implizites Wissen. Also der Naur hatte auch hier so implizites Wissen, die Bedeutung des impliziten Wissens hervorgehoben und also implizites Wissen heißt, Man kann das irgendwie schlecht dokumentieren, oder es ist unheimlich schwer. Und weil es halt sozusagen dieses tiefe, oft ungesagte Wissen zwischen Entwicklern, das kannst du eigentlich nicht über Dokumentation teilen. Es ist die Frage, wie oder was denkst du, welche Arten von Dokumentationen sind eigentlich sinnvoll, so mit Hintergrund von dem von Peter Naurs Paper?

Daniel: Ja, ja, also was auf jeden Fall nicht man daraus schließen sollte, meiner Meinung nach, ist, dass man dann einfach keine Dokumentation mehr macht, nur weil die Dokumentation alleine nicht hilft, die Theorie zu bilden für neue Teammitglieder. Dann wäre ja die Konsequenz im Grunde, dass die Theorie so eine Art Schamanenwissen ist. so aus der vorschriftlichen Zeit. Sie wird halt wirklich nur mündlich aus dem einen Kopf zum anderen weitergegeben, von einer Generation zur nächsten. Das ist ja scheinbar ein wichtiger Aspekt, aber trotzdem wurde Schrift ja erfunden und man sollte sie sich vielleicht trotzdem irgendwie zunutze machen.

Sven: Wie bei den Druiden bei Asterix und Obelix, die hatten schon die Schrift, aber die haben auch gesagt, das wird nur mündlich durch Erzählungen weitergeführt.

Daniel: Ja, im Grunde hat mich das halt an dieses Schamanen-Art erinnert. was da über diese First- und Second-Generation-Programme, was so gesagt wurde von Baldu und was auch in dem Paper steht. Aber nichtsdestotrotz ist Dokumentation sinnvoll. Der Baldu Bjarnason sagt ja, die meiste Codokumentation ist nicht hilfreich, um sich die Theorie anzueignen. Sie wird erst nützlich, nachdem man bereits eine Theorie des Programms entwickelt hat und dient dann so als Gedankenstütze. und nicht als Werkzeug zum Lernen. Ich bin mir nicht sicher, ob ich das hundertprozentig so sehe. Vielleicht kann man das über Code-Dokumentation so sagen. Aber ein bestimmtes Minimum an Architekturdokumentation finde ich dann trotzdem sinnvoll. Also insbesondere Architekturziele, Architekturentscheidungen. und auch vielleicht die verwendeten Metaphern und Patterns erklären. Wir machen ja viel mit architecture decision records auch, zumindest in vielen Projekten, in denen ich jetzt so war. Und da ist ja auch ein wichtiger Bestandteil immer das Warum. Also nicht nur irgendeinen Zustand beschreiben, sondern auch erklären, warum man etwas getan hat, welche Alternativen man aus welchen Gründen verworfen hat.

Sven: Das ist ein guter Punkt. Da hat dann Baldo nämlich vielleicht doch recht. Die ADRs sind die Gedankenstütze für den First Generation Developer, der noch da ist, damit er nicht alles komplett im Kopf haben muss. Also als Gedankenstütze. Und dann kann ich das benutzen, um dieses Wissen weiterzugeben, auch auf mündlicher Art vielleicht.

Daniel: Ja.

Sven: Genau, ich denke, so ein Doku zeigen, also ich finde Doku zeigen gut, wenn es so einen kurzen Überblick gibt. Also keine Ahnung, wir haben ja auch hier die Architecture Communication Canvas, wo man halt so relativ kurz einfach sieht, was ist wichtig an dem System, wieso ist das System überhaupt wie es ist, was sind die wichtigsten Stakeholder, die wichtigsten Ziele und so weiter. Aber wenn man dann in die Details geht, dann denke ich auch, für mich ist das eher so eine Gedankenschutze. Für mich, wenn ich mit Leuten, wenn ich der second generation erklären will, warum die Welt so ist, wie sie ist, ja.

Daniel: Ja, genau.

Sven: Ich finde es auch wichtig, dass man, also gerade bei ADRs, denke ich, da ist es wichtig, dass man die von Anfang an macht. Also ich habe es auch mal bei einem Projekt erlebt, da war Kent Beck, von Anfang an war der der initiale Consultant, so Rob Mee und Jutta Eckstein und so weiter. Und das ist schon ewig her. Und da war wirklich so extrem mit, hier wird überhaupt nichts dokumentiert. Also die Dokumentation ist praktisch das Schamanenwissen. über Pairing wird sozusagen alles weitergetragen. Und ich muss sagen, das hat erstaunlich gut funktioniert. Also auch, weil die Leute natürlich relativ lange dabei waren. Also das hat wirklich gut funktioniert. Aber es gab halt ganz viele Stellen, wo man dann gedacht hat, Also ich habe jetzt echt keinen Bock mehr darüber zu reden oder ich kann mich nicht mehr so genau erinnern. Hallo, wer kann sich denn nochmal genau erinnern, warum wir das so und so gemacht haben? Und dann haben wir tatsächlich angefangen, irgendwann so nachzudokumentieren. So gewisse Dinge, da fällt halt auf, die musst du einfach haben. Sonst wird es einfach zu anstrengend, sich da immer wieder dran zu erinnern.

Daniel: Ja, und man könnte ja auch sagen, die Leute wollen nur so, dass alles im Kopf haben, damit sie unersetzbar sind und wertvoll. Könnte zumindest ein Gegenargument sein von Managern.

Sven: Ja, also ich meine, ich hatte ja auch mal den Fall, da hat jemand gesagt, ich kündige und dann hat der Manager gesagt, du kannst nicht kündigen, wenn du kündigst, dann ist dieses Projekt im Arsch. Ich meine, ich weiß, aber ich kündige und dann meinte der Manager, naja, Was können wir denn tun, damit du bleibst? Da auf dem Platz, der Joost, der da sitzt, der soll da morgen nicht mehr sitzen. Okay, wir können den umsetzen. Ist kein Problem. Das meine ich nicht. Nix umsetzen. Aus dem Gebäude entfernen. Ja, und dem blieb nichts anderes übrig, als den zu entfernen. Das war schon heftig. Gut. Genau.

Daniel: Ja, das sind aber nicht die Vorteile, die wir uns erhoffen von Programmieren als Theoriebildung.

Sven: Vielleicht als letzten Punkt, die langfristige Pflege. Also Peter Naur, der weiß daraufhin, dass sozusagen die Fähigkeit, Software langfristig zu warten und anzupassen, halt direkt mit dem Verständnis von der Theorie zusammenhängt. Und ja, das hatten wir auch schon so erwähnt, wenn neue Entwickler ein Projekt kommen, dann müssen sie nicht nur den Code, sondern auch die Theorie verstehen. Da hast du auch so ein paar Ideen, sozusagen bei Baldur, Bjarneßen und so weiter, rausgesucht, wie man das ganz gut hinbekommen kann. Stimmt, ja, stimmt, genau.

Daniel: Ja, also Baldr hat das natürlich auch nicht selbst sich ausgedacht. Ich glaube, der hatte auch auf irgendein anderes Buch verwiesen. Ich glaube sogar von den Basecamp Leuten kam das eigentlich. Ja, also diese Slack oder Cool-Off-Zeiten schlägt er vor in seinem Buch. Und ja, da geht es einfach darum, dass ich zwischendurch immer wieder mal Zeiten habe, wo ich jetzt keine neuen Features entwickeln muss, sondern im Grunde kann ich machen, was ich für richtig halte. Das kann auch einfach bedeuten, ein tieferes Verständnis der Theorie entwickeln, indem ich durch den Source Code durchsteige, vielleicht auch Sachen verbessere dabei natürlich, ein bisschen Software Gardening mache. Solche Dinge halt.

Sven: Ich bin ja großer Freund von diesen Cool-Off-Zeiten. Da war mein zweites Projekt nach dem Studium. Das ist 18 Jahre her und traurigerweise immer noch das beste Projekt ever. Da hatten wir tatsächlich diese Cool-Off-Zeiten. Wir hatten so extrem harte Deadlines. Das waren so öffentliche Termine. Ja, bis zu der Deadline war natürlich ein Haufen Hektik. Und danach haben die sich drei Wochen nicht gemeldet und haben gesagt, mach, was du dir wollt. Das hatten wir so mehrmals im Jahr. Die Software war einfach in extrem gutem Zustand. Also jetzt vergleichsweise zu anderen Projekten, würde ich mal sagen. Aber wir hatten eigentlich auch so diese Zeit für diese Verbesserungen. Also überlegen, was läuft hier eigentlich nicht so gut? Und ich fand das wirklich total super. Aber die Frage ist, ist das überhaupt realistisch so cool auf Zeiten? Also offensichtlich bei dieser Firma war das so. Ja.

Daniel: Ich habe das auch schon erlebt, dass das möglich war, aber ohne es explizit sogar einzufordern. Ich hatte auch mal einen Arbeitgeber, wo ganz klassisch, glaube ich, dann zweimal pro Jahr ein Release war oder so. Und dann wurde halt erst mal alles eingefroren zu einem bestimmten Zeitpunkt. Und dann durftest du auch keine neuen Features entwickeln, weil du musstest im Grunde auf Abruf bereit sein, dann irgendwelche Bugs zu finden, die dann gefunden wurden in dieser Testphase. Und die Zeit haben wir dann schon auch genutzt, um Verbesserungen vorzunehmen, technischer Art. Also im Grunde war das eine Cool-of-Zeit, die wir uns einfach selbst dann genommen haben, weil man sonst ja nur Däumchen gedreht hätte.

Sven: Ja, das stimmt. Ich denke mir auch, wenn die Basecamp Leute das machen, also Paper verlinken wir auch, dann machen ja in aller Regel schlaue Dinge, würde ich mal so behaupten. Da können wir uns darüber nachdenken, aber ich habe ja so, also ich mache ja so Workshops, so Managing Technical Depth Workshops und da ist sozusagen so eine, gibt so ganz viele Alternat, also ganz viele Optionen, wie man so machen kann und diese, diese cool off Zeiten, die schlage ich auch immer vor mit ihren Vor- und Nachteilen. Und das wird sozusagen immer lachend abgewehrt. Die Leute sagen, das ist eigentlich eine ganz nette Idee, das wird uns wirklich weiterhelfen, aber das ist zu absurd. Da wird niemand zustimmen.

Daniel: Ja, also eine Alternative, die ich da noch sehe, ist eben, dass man diese Tätigkeiten, die man sonst in der Cool-Off-Zeit macht, begleitend dann in der Feature-Entwicklung mitmacht. Aber dann würde man halt entsprechend ein bisschen länger für die Features brauchen. Es kann aber ja eigentlich auch ganz gut sein, technische Schulden dann schon direkt anzugehen, wenn man ein Feature umsetzt, was damit zu tun hat. Das ist halt dann auch die Fall. Im Grunde merkt dann das Management das halt nur nicht so klar, weil man es halt permanent ein bisschen macht.

Sven: Da könnte ich auch nochmal ein Paper verlinken von dem oben genannten George Fairbanks. Der hat auch noch mal so ein interessantes Payment zu Technical Debt Management, also das jetzt einigermaßen neu ist, rausgebracht, wo er im Prinzip auch die unterschiedlichen Optionen noch mal durchgeht. Und das, was du genannt hast, also wie kann man eigentlich effektiv in diese Vermeidung gehen, was Theory Building zum Beispiel auch angeht. Also einfach jetzt nicht irgendwie das Ding runter programmieren, dann refactoren, sondern immer noch mal vorher überlegen, Also im Grunde genommen wird du ganz am Anfang gesagt, es gibt ja eigentlich gibt es immer nur eine Option oder ganz es gibt ganz wenige Optionen und dass man halt so lange darüber nachdenkt und diskutiert, bis man weiß, was ist denn eigentlich diese Option, die ich da umsetzen muss.

Daniel: Ja. Ja. Genau, also letztlich

Sven: Genau, die diskutierte First- und Second-Generation-Developer-Denke, die hilft da auch, oder? Also bei langfristiger Pflege. Im Prinzip passt er da auch perfekt rein.

Daniel: Was Baldur Beatnersson sagt, ist ja eben auch, dass so Sachen wie diese Cool-Off-Zeiten eben auch den Second-Generation-Developern helfen, ihr Verständnis zu vertiefen. Um dann irgendwann auch auf dem Niveau eines First-Generation-Developers zu sein. Du hast halt nicht diesen Druck, jetzt irgendwie einen Feature gerade umzusetzen permanent,

Sven: Ja, wie würde ich das, also wie würde mir das als Second Generation helfen, dass ich so eine Cool-Off-Zeit habe? Und, ja, okay, und einfach in Ruhe auch mit den Leuten diskutieren. Ja, ja.

Daniel: Kannst dich auch wirklich mal mit dem Source Code auseinandersetzen. Einfach. Das auch sicherlich genau.

Sven: Okay. Ja, jetzt haben wir schon wieder eine Stunde rum. Haben wir dafür noch Zeit? Okay, okay. Das muss sein, okay. Genau, der Alistair Coburn, der hat hier in seinem Buch Lass uns doch mal auf den letzten Punkt noch kommen. Ja, zwei, drei Minuten noch. hat er viele Bücher geschrieben. Man hat so ein Buch, Agile Softwareentwicklung, glaube ich, so heißt es. Da hat er ja das Paper auch komplett abgedruckt. Und da sagt er halt, naja, diese Modellbildung, die gibt es natürlich auch im Extreme Programming. Also er sagt halt, Modellbildung im Extreme Programming ist sozusagen das, wird abgebildet durch das Konzept der Metapher, die praktisch diese Theoriebildung unterstützt. Metaphern helfen, komplexe Softwarekonzepte in verständlichere Formen zu übersetzen, was sozusagen die Kommunikation innerhalb von so einem Team und das Verständnis der Software fördert. Das fand ich da ganz interessant. Ich muss sagen, relativ lange habe ich dieses Metapherkonzept in XP gar nicht so richtig verstanden, weil da irgendwie so die Beispiele mir initial gefehlt haben. Aber dann so nach und nach hat sich das so entwickelt, weil ich immer so gedacht habe, diese ganzen ehemaligen Pattern-Leute und Extreme Programming kommt ja auch viel so aus der Pattern-Ecke. Kent Beck hat ja auch Smalltalk Patterns und so geschrieben davor. Dass die halt, was mich fasziniert hat, war, dass die so diese Fähigkeit hatten, irgendwelche Sprüche zu kreieren. Das waren wahrscheinlich die Metaphern und diese Sprüche haben sozusagen die Essenz von irgendeinem Konzept zusammengefasst und man konnte das irgendwie gar nicht mehr so richtig aus dem Kopf bekommen. Das fand ich da eigentlich immer ganz, ganz gut. Also so als Beispiel, jetzt zum Beispiel bei einem Projekt, das wir hatten, da hatten wir irgendwie gesagt Dump Pipes, Smart Endpoints, das ist unsere Architektur sozusagen. Und sind eigentlich nur vier Worte und wenn sich das in allen Köpfen sozusagen rein brennt, dann ist immer klar, wie wir eigentlich unsere Entscheidung treffen sollen. Also die, es gibt keine.

Daniel: Ja. Ja. Dann weißt du, wenn du eine Anforderung hast, was zu ändern oder anzupassen, genau woran du dich orientieren musst. Also die richtige Lösung quasi, anstatt der vielen anderen möglichen Lösungen, die liegt dann doch eben recht nahe, wenn man diese vier Worte halt immer vor Augen hat.

Sven: Ja, manchmal war es auch schwer. Weil dann sagst du halt, na ja, es gibt eine Lösung, die ist einfach. Aber die passt halt nicht in dieses Konzept Dump Pipe Smart Endpoints. Was machen wir denn jetzt? Ja, wir überlegen so lange, bis wir eine Lösung haben, die da reinpasst. Vermutlich.

Daniel: Ja. Genau, genau. Wie? Ja. Ja klar, trivial ist das nicht immer, aber zumindest weiß man, welche Lösungen nicht passen und dann muss man sich überlegen, was man tut.

Sven: Genau, ein anderes schönes Konzept, finde ich, ist auch von INNOQ kleine Monolithen. Also wir finden Monolithen so super. Wir lieben sie so sehr, dass wir ganz viele davon haben wollen. Die sind halt ein bisschen kleiner und wir springen praktisch über links von System zu System, also von Monolith zu Monolith. Und das fand ich eigentlich auch immer eine ganz nette Art, so grundsätzlich so ein System zu verstehen.

Daniel: Ja, genau. Also es ist natürlich sehr high level in diesem Fall auch oder beides eigentlich so auf der Architektur Ebene oder Systemarchitektur Ebene. Aber natürlich könnte man solche prägnanten Aussagen und Metaphern auch dann innerhalb eines kleineren Systems sicherlich gut unterbringen.

Sven: Es kann auch mehrere von diesen Sprüchen geben. Also ich hatte mal so ein Podcast zu Architekturprinzipien gemacht, also der können wir auch mal verlinken, der Martin Fowler und die Birgitta Böckeler, die hatten mal so einen Vortrag darüber gemacht. Und die haben halt auch gesagt, so ein Architekturprinzip ist ja im Prinzip auch so eine Leitlinie, die uns einfach helfen soll, Entscheidungen zu treffen, also konsistente Entscheidungen im Sinne von irgendwas, was uns wichtig ist. Und die haben auch gesagt, der catchy Title, der ist total wichtig. Also es muss sich irgendwie, das ist alles schön und gut, wenn du Codebeispiele hast und wenn du dokumentierst, du brauchst diesen catchy Title, damit du, das musst du immer wieder aus dem Hut zaubern. Und dann, dann können sich die Leute dran erinnern. Was zu tun ist.

Daniel: Ja. Ja.

Sven: So einen hätte ich noch, weil den finde ich total schön. Und zwar der Gregor Hoppe. Der hat, der finde ich, der ist auch super, was so diese Metaphern angeht oder diese Essenz. Und der hat ja auch immer, der sagt ja immer Cloud is a lifestyle change. Das nennt irgendwie so, ich ändere meine Infrastruktur. Sondern wenn ich zur Cloud wechsle, bedeutet das nicht, dass ich so weitermach wie gehabt. nur halt jetzt auf Cloud-Infrastruktur, sondern das ist eigentlich Softwareentwicklung anders gedacht. Also es ist sozusagen, du hast einen anderen Lifestyle. Und das finde ich eigentlich auch ganz, ganz schön. Na, ja.

Daniel: Das betrifft ja eigentlich alle Technologieänderungen. Wenn ich neue Technologien einführe in einer Organisation, dann bleibt halt nicht alles andere gleich. Prozesse und so weiter. Oder zumindest kann ich dann nicht davon profitieren, wenn ich einfach alles andere gleich lasse.

Sven: Genau, genau. Also die alten Technologien, damit die gut funktionieren, gibt es irgendwelche Regeln drumrum. Und wenn ich jetzt die neuen Technologien einführe und die alten Regeln beibehalte, dann bleibt eigentlich alles gleich schlecht.

Daniel: Ja, das wird vielleicht sogar noch schlechter, weil das nicht dazu passt.

Sven: Ja, das könnte sein. Ja, genau, genau. Ja, da gibt es leider nicht als Buch, das gibt es nur als Hörbuch. Und zwar Elias Goldrad. Also der hat irgendwie The Goal geschrieben. Also das Ziel dieses Buch Theory of Constraints, was im Prinzip hier von den ganzen DevOps Leuten immer referenziert wird. Und er hat ein Hörbuch Beyond The Goal, wo er im Prinzip in einem Kapitel so eine Stunde lang praktisch sagt, ja, wenn du, ja, wenn du dein, wenn du neue Technologie hast, aber deinen Lifestyle nicht änderst, dann wird das alles nix mit der neuen Technologie. Ja.

Daniel: Aber wir driften vom Paper ab. Man merkt, wir sind durch. Genau, und das hat halt Konsequenzen auch

Sven: Genau. Genau, genau, genau. Aber ich denke, was wichtig ist, also ist aus meiner Sicht, dass wir schon ziemlich viele Gedanken in diese, also in so eine konsistente Theoriebildung stecken müssen. eigentlich für fast alles, für Staffing, auch für Dokumentation.

Daniel: Ja, und auch generell für den ganzen Entwicklungsprozess.

Sven: Also zusammenfassend, was würden wir tun? Wir versuchen das Problem zu verstehen, indem wir ziemlich viele Tools anwenden, wie wir Probleme verstehen können, wie meinetwegen Pairing oder Ensemble Programming, Event Storming und so weiter. Und wie du sagst, über Stuffing, also dass wir halt einfach sagen, wir versuchen wirklich Leute längerfristig zu halten.

Daniel: Ja, und wir versuchen eben dann auch die Theorie in die nächste Generation oder die Köpfe der nächsten Generation weiterzugeben, auch über einige dieser Tools. Ja, ja, und auch dann die Übergabe zum Kunden eben auch so zu gestalten, dass das Wissen nicht verloren geht oder die Theorie.

Sven: Okay. Hast du noch final words, irgendwas, was wir vergessen haben?

Daniel: Nee, ich glaube nicht. Vielleicht sollten unsere Hörerinnen das Paper einfach mal lesen. Das ist ziemlich kurz. Das ist sprachlich, finde ich, ein bisschen schwierig jetzt nicht, aber ich fand es ein bisschen… Ja, musste man sich daran gewöhnen an diesem Sprachstil, aber es ist jetzt kein schwieriges Paper eigentlich.

Sven: Ja, wir können sie auf jeden Fall verlinken.

Daniel: Ja, es gibt irgendwie zig verschiedene Quellen, wo Leute das mal irgendwo dann integriert haben. Ich weiß gar nicht, ob irgendwo das Original noch herumfliegt.

Sven: Am liebsten wäre es, also ich glaube öffentlich verfügbar ist auf jeden Fall das von Alistair Cockburn in ziemlich guter Qualität, weil es halt nicht irgendwie aus den 80er Jahren abfotografiert ist und dann hat man direkt noch diesen agilen Softwareentwicklungstouch und sowas dabei.

Daniel Westheide: Genau. Interessant. Das ist ein guter Tipp. Wenn zgpt das korrekt zusammengefasst hat.

Sven: Ja, und also was ich gemacht habe, bevor ich es gelesen habe, habe ich es zusammenfassen lassen von chat.gbt und dann ist es tatsächlich, da ist mir deutlich einfacher gefallen, das zu lesen, muss ich sagen.

Daniel: Ja. Ja.

Sven: Ja, auch wenn nicht. Man kann sich ja nie so hundertprozentig drauf verlassen, aber ich würde sagen, so der 70% falsch ist das schon okay. Aber mir ist halt einfacher gefallen, das Paper zu lesen, nachdem ich so die Zusammenfassung gelesen habe. Wie du schon sagst, manchmal ist es nicht ganz so einfach zu folgen, aber wenn man schon irgendwie weiß, worauf man hinaus will, ist es dann doch wieder einfacher. Okay, dann vielen Dank Daniel und den Zuhörern fürs Zuhören. Bis zum nächsten Mal. Tschüss.

Daniel: Ja, alles klar. Ja, danke für die Einladung. Bis dann. Tschüss.