# Programming as Theory Building: Implications for AI

**Podcast:** Software Architektur im Stream
**Published:** 2026-02-28

## Transcript

Hallo, ich bin Iberhard Wolf.
Freitags mache ich oder Lisa Moritz ein Livestream zum Thema Softwarearchitektur, oft zusammen mit Gästen.
Dieser Podcast ist das Audio des Streams.
Weitere Folgen, Sketchnotes und vieles mehr findet ihr unter software-architektur.tv.
Softwarechitektur im Stream.
So, dann herzlich willkommen zu einer weiteren Episode von Softwarechitektur im Stream.
Heute geht es um das Thema Programmierung als Theoriebildung.
Und das wird so ein bisschen sozusagen vorlesungsmäßig.
Das heißt, ich diskutiere ein Paper von dem Peter Auer.
Und von 1985, wo es eben also um Programmierung eben als Theoriebildung geht.
Der ist so ein bisschen bekannter.
Einmal, weil er mit an der Backusnauer Form für die Syntax von Programmiersprachen gearbeitet hat.
Der ist an Algol 60 beteiligt gewesen, einer der ersten so strukturierten Programmiersprachen.
Und außerdem war der Mann von der Christiane Freud, mit der wir auch schon mal eine Episode gemacht haben.
Er ist mittlerweile leider verstorben.
Und die Episode mit der Christiane Freud, Professor Christiane Freud verlinke ich auch nochmal.
Und ja, warum dieses Thema?
Gerade so angesichts dessen, dass es halt die Idee gibt mit LLMs und AI-Software zu entwickeln, habe ich halt das Gefühl, dass so ein paar grundlegende Ideen davon, was eigentlich Softwareentwicklung ist, unklar sind.
Und da ist es irgendwie, glaube ich, sinnvoll, sich so ein paar grundlegende Sachen irgendwie nochmal anzuschauen.
Ralf hatte auch darauf hingewiesen, also Ralf D.
Müller, mit dem wir den Stream machen, dass das halt vielleicht ein interessantes Paper ist und dass das halt irgendwie auch Auswirkungen auf die Softwareentwicklung mit der AI hat.
Und deswegen hatte ich halt gedacht, schaue ich mir das halt sozusagen mal an.
Worum geht es in dem Paper?
Also, das Paper ist im Programming is Theory Building.
Und er sagt halt in der Intro, dass seiner Meinung nach die Programmierung eine Aktivität ist, bei der Programmierin eine Theorie über die Realität entwickeln.
Das ist etwas, was aus seiner Sicht aus Beobachtung geboren ist.
Und warum er dieses Paper halt geschrieben hat, ist, weil wenn man nicht versteht, was man tut, kann man auch nicht die Herausforderungen verstehen, die sich daraus halt ergeben und man kann sie halt eben auch nicht lösen.
Und das ist, glaube ich, ein sehr guter Punkt und ein sehr guter Grund, weswegen man sich damit beschäftigen will.
Das Papier hat verschiedene Kapitel.
Das erste ist Programming and the Programmer's Knowledge, also Programmierung und das Wissen von ProgrammiererInnen.
Ich werde versuchen, ich weiß nicht, ob ich das schaffe, in dieser Episode tatsächlich von Programmierung zu reden, weil das ist der Begriff, den er sich halt gewählt hat.
Nicht Software Engineering.
Und er will aber unter Programmierung eben alles verstehen, nicht nur das Generieren von Code, sondern auch irgendwie Design und auch Implementierung.
Und ich fand das eigentlich einen sehr sympathischen Teil von diesem Paper, dass er ihm gesagt hat, naja, nicht, also Programmierung ist eben nicht nur Coproduktion, sondern es ist mehr.
Und dieser Begriff von Software Engineering, der ja tatsächlich älter ist, also den es durchaus 1985 schon gab und der ihm sicher auch bewusst war.
Ich weiß nicht, ob er dem bewusst nicht gewählt hat, aber nicht, also Programmierung als sozusagen die Tätigkeit zu werden, fand ich jetzt erstmal gut.
Und er behauptet halt, dass Programmierung ist, dass sich irgendetwas in der realen Welt in Verbindung mit der Manipulation von Symbolen durch einen Computer bringen.
Was also bedeutet, dass ich eben ein Programm schreibe, was er Symbole interpretiert, ändert und dass das irgendeine Verbindung hat mit der realen Welt.
Also so ein bisschen, würde ich sagen, Modellbildung, darüber habe ich ja auch schon mal gesprochen hier in dem Stream, so in diese Richtung geht das.
Und seine weitere Aussage ist halt, wenn sich diese Tätigkeit ändert, die dort also im Computer abgebildet oder unterstützt wird, dann muss sich eben auch das Programm ändern, was halt wiederum bedeutet, dass halt ProgrammiererInnen Wissen über die Welt aufbauen.
Und das reflektiert sich halt anschließend in dem Programm.
Soweit also sozusagen der Prolog.
Und er hat dann zwei Case Studies, die er halt zitiert.
Ich nehme an, das ist seine eigene Erfahrung.
Und die erste Case Studies hat ein Compiler.
Und zwar baut halt eine Gruppe, eine Gruppe A, ein Compiler für ein Computer X.
Und dann soll eine Gruppe B ein Compiler für einen anderen Computer, also für einen Computer Y bauen, der eine erweiterte Sprache kompiliert im Vergleich zu dem, was eben die Gruppe A gebaut hat.
Das heißt also, es gibt zwei Änderungen.
Einmal einen neuen Computer unterstützen oder einen anderen Computer unterstützen und zum anderen eine Erweiterung der Sprache hinbekommen.
Und die Gruppe B hat sich ja mir dazu entschieden, den Compiler, den die Gruppe A gebaut hat, dafür zu verwenden.
Und während der Designphase, also nicht offensichtlich ein phasenorientiertes Vorgehen, läuft die Gruppe B zu der Gruppe A und gibt denen verschiedene Vorschläge für die Erweiterung des Compilers für eben diese Erweiterung der Sprache.
Das heißt also im Prinzip sagt Gruppe B, kommt mal zu, können wir den Compiler folgendermaßen ändern.
Und die Gruppe A sagt dann ja oder nein.
Und es stellt sich dabei halt heraus, dass die Gruppe B Erweiterungen vorschlägt, die eben nicht die Vorkehrung im Compiler verwenden, die dafür vorgesehen sind.
Diese Vorkehrung sind ausführlich dokumentiert, so die Aussage.
Und stattdessen ist das Design, was die Gruppe B typischerweise vorschlägt, so gestaltet, dass es halt die Einfachheit und Mächtigkeit des Compilers zerstört.
Und Gruppe A kann das relativ schnell herausfinden und deutlich bessere Alternativen vorschlagen.
Das ist also für Gruppe A nichts, was jetzt intellektuell herausfordernd ist, sondern das ist für sie tatsächlich relativ einfach.
Und das andere, was Nauer beschreibt, ist halt, dass später eine weitere Gruppe, also eine Gruppe C diesen Compiler übernommen hat von der Gruppe B und dann tatsächlich eben die Struktur ineffektiv geworden ist.
Die haben eben dann nicht mehr mit der Gruppe A gesprochen, die haben das halt so erweitert, wie sie es sozusagen für sinnvoll erachteten.
Und dadurch ist dann eben ein System entstanden, das tatsächlich ineffektiv ist und das dann irgendwie tatsächlich zu einem Problem führt.
Jetzt muss ich mal schauen, da ist ein Kommentar auf YouTube.
Who you're gonna call, schreibt, ProgrammiererInnen bauen, wissen über die Welt auf.
Die Welt kann das eher kann das ein anderes Team sein.
Meinst du damit ein Team immer eine Umwelt?
Nee, ich meine halt die Welt, also die Welt, in der das Programm halt irgendwie funktionieren soll und letztendlich eben das Problem, was eben das System lösen soll.
So, zweite Case Study ist ein Real-Time-System für industrielle Produktion.
Und dort gibt es zwei unterschiedliche Gruppen.
Es gibt eine Gruppe, die für jede Installation individuelle Anpassungen macht an dem System.
Das heißt, es gibt sozusagen ein Grundsystem, das wird halt irgendwo installiert bei irgendwelchen industriellen Produktionen und irgendjemand baut halt diese Anpassung.
Und die was Nauer jetzt eben beschreibt, ist, dass er nennt sie, also ich habe es übersetzt mit Bug Beseitigen ProgrammiererInnen, also Leute, die eben sozusagen das System warten, so würde man es, glaube ich, heutzutage sagen.
Die arbeiten halt schon sehr lange mit diesem System.
Und die anderen bauen eben diese individuellen Anpassungen.
Und wenn diese Teams, die halt die Anpassungen bauen, eben damit beschäftigt sind, Anpassungen zu bauen.
Dann kommen sie halt manchmal zu diesen WartungsprogrammiererInnen und sagen halt, hey, hier sind halt, ich habe Fragen oder Schwierigkeiten, und das können irgendwie diese WartungsentwicklerInnen relativ einfach lösen, beziehungsweise es basiert meistens auf mangelndes Verständnis der Dokumentation.
So, was es jetzt bedeutet, ist, dass in beiden Fällen ja offensichtlich eine Gruppe existiert von Menschen.
In dem ersten Fall ist das die Gruppe A, die den ursprünglichen Compiler gebaut hat.
In dem anderen Fall sind es diese WartungsprogrammiererInnen, die halt tatsächlich das System weiterentwickeln können.
Und irgendwie scheinen die sich von anderen Leuten, die sich mit dem System und dem Code auch beschäftigen kann, signifikant zu unterscheiden und haben deswegen da irgendwie eine Art von Herausforderung.
Der Christian, Christian Beuthenmüller, 1295 bei YouTube sagt, ja klar, man wird immer Expert in der Domäne, in der man arbeitet.
Ja, stimmt.
Aber also bei dem Compiler zumindest ist ja die Domäne eben Compiler.
Und mein Problem, das wollte ich eigentlich später diskutieren, ist, dass es für mich schwerfällt zu sagen, es gibt sozusagen eine Domain Compiler.
Und der Impact of the real Welt ist ja auch nicht so einfach to see.
Also, Compiler ist tatsächlich eben ein Werkzeug, was EntwicklerInnen benutzt.
Und das hat höchst indirekte Auswirkungen auf die reale Welt.
Das ist was anderes, wenn ich halt bei dieser industriellen Produktion ist klar, dass es halt ein Ding ist, wo ich halt sehen kann, was es eben tut, indem ich mir die Produktion angucke.
Aber bei dem anderen ist es halt was anderes.
Trotzdem gibt es ja in beiden Fällen offensichtlich irgendein Wissen, was eine bestimmte Gruppe hat, das dazu führt, dass diese Gruppe diese Software besonders gut ändern kann.
So, er geht dann ein auf Ryles Begriff einer Theorie.
Und er sagt halt, also offensichtlich jemand, der sich mit dem Begriff Theorie insbesondere auseinandersetzt.
Ich habe mir den Teil ehrlich gesagt nicht so ganz detailliert angeguckt in dem Paper.
Und er sagt dort, oder der Ryle sagt halt offensichtlich, dass eine Person mit einer Theorie weiß, wie man Dinge tut und kann sie erklären, begründen und Fragen dazu beantworten.
Das heißt also, und weiter unterscheidet Ryle offensichtlich zwischen intelligentem Verhalten.
Wenn ich also zum Beispiel Fische oder grammatisch korrekt spreche, dann sind das eben Dinge, die ich, die halt intelligentes Verhalten darstellen.
Mit intellektuellem Verhalten, Intellectual im amerikanischen Englischen Original, habe ich aber dann eine Theorie.
Und also das passt halt beispielsweise dazu, dass halt Menschen vielleicht grammatisch korrekt sprechen können, aber sie lernen dann irgendwie retrospektiv in der Schule erst die Theorie dahinter.
Und darüber halt irgendwie nachzudenken, das ist eben diese Theorie, die halt aufgebaut wird.
Das gilt zum Beispiel auch für alltägliche Dinge wie Reiseplanung.
Also, ich, das ist das, was halt im Paper als Beispiel genannt wird.
Ich nehme an, dass damit so etwas gemeint ist, wie ich kriege halt irgendwann eine Idee davon, wer mit der Deutsche Bahn arbeitet.
Es kriege ich vielleicht eine Idee davon, wie Flughäfen arbeiten und kann dadurch halt mich sozusagen anders verhalten.
Genau, Christian Beuthenmüller schrieb: Die Domäne bei Compilern ist die reale Welt des Chipsatzes und der Spezifikation der Premiersprache, also C für X86 oder ARM oder sowas.
Wie gesagt, wir kommen später dazu.
Ich muss gestehen, dass ich ein bisschen unter dem Eindruck, also wie soll ich sagen, ich würde dir recht geben, ich glaube, es gibt Leute, die damit Schwierigkeiten haben.
Wir diskutieren es dann hier nochmal später.
Genau.
So zurück zu diesem Thema mit der mit der Theorie.
Das bedeutet also, es muss irgendwie ein Zusammenhang zwischen Realität und Theorie geben.
Und der muss irgendwie klar sein, nur weil ich ja wie Newtische Mechanik irgendwie verstehen habe, verstehe, bedeutet es noch lange nicht, dass ich halt weiß, wie ich sie benutze.
Das heißt, ich kann damit zwar theoretisch berechnen, wie halt ein Ball fliegt oder bestimmte andere Dinge halt berechnen, aber ich muss eben verstehen, wie halt die Dinge angewendet und genutzt werden.
Und die Aussage, die jetzt eben in dem Paper steht, ist, dass er im ProgrammiererInnen eine Theorie entwickeln, wie bestimmte Elemente der Realität durch ein Programm abgewickelt oder unterstützt werden sollen.
Und seine Aussage ist jetzt, dass eben diese Theorie wichtiger ist als der Code, die Dokumentation oder die Spezifikation, sie ist das, was ja offensichtlich Menschen dazu befähigt, mit dieses System zu ändern und zu verstehen.
Und er fragt dann irgendwie auch nicht, wo, also er geht der Frage, nach wo genau diese Theorie wichtig ist.
Und das ist eben wichtig, an der einmal damit ProgrammiererInnen verstehen, was der Bezug zwischen dem Programm und der realen Welt ist.
Dann zum zweiten, ProgrammiererInnen können erklären, was jeder Teil des Programms ist und was er tut.
Und da kann man natürlich sagen, naja, also es gibt halt irgendwie Prinzipien, also wir kennen halt alle verschiedene Design-Patterns, wir können über Microservices reden, Schichten oder was auch immer.
Und das ist zwar natürlich so, aber wir müssen trotzdem, oder das ist eine Aussage, selbst wenn das System solche Prinzipien nutzt, ProgrammiererInnen wissen, welche genutzt werden.
Und also aus meiner Consulting-Vergangen-Erfahrung würde ich halt hinzufügen, häufig werden diese Prinzipien halt auch fehlverstanden oder halt irgendwie modifiziert.
Und deswegen nützt es halt wenig, wenn man halt sagt, ich benutze halt eine hexagonale Architektur oder wir machen halt Schichten oder wir machen Microservices.
Weil wenn man dann tiefer gräbt, stellt man halt fest, dass in Wirklichkeit es halt irgendwie komplizierter ist, dass es halt an bestimmten Stellen Verstöße gibt und so weiter und so weiter.
Dann die dritte Sache ist, ProgrammiererInnen können etwas dazu sagen, wie das Programm auf Änderungen in der realen Welt reagieren kann.
Dazu muss man die Ähnlichkeit der Änderungen zu den umgesetzten Anforderungen verstehen.
Das bedeutet also, wenn ich jetzt irgendwo eine Änderung machen will.
Wir hatten zum Beispiel dieses Beispiel, dass ich halt eine andere Programmiersprache unterstützen möchte und ein anderes Ziel für einen Compiler.
Da muss ich mir halt irgendwie überlegen, wie ähnlich diese Sachen sind gegenüber dem, was ich umgesetzt habe und wie ich das dann irgendwie ansprechen, sozusagen in diese Theorie und damit letztendlich in das Programm einbaue.
Und Ähnlichkeit, wäre halt meine Ergänzung, ist etwas, was im hohen Maße subjektiv ist.
Und tatsächlich, glaube ich, wahnsinnig schwer zu klassifizieren ist.
Also, wie sind Dinge ähnlich?
Eine Maus ist halt ein Säugetier, genauso wie ein Wal, ist in gewisser Weise also ähnlich.
Wenn ich mir wahrscheinlich das Genomen ansehe, sind sie wahrscheinlich wahnsinnig ähnlich.
Aber natürlich ist es halt, wenn ich mir sie angucke, vielleicht irgendwie nicht so.
So, das nächste Kapitel, was er halt hat, ist diese Geschichte mit Problemen und Kosten von Programmänderung.
Also Software wird halt modifiziert, das ist dann unsere große Herausforderung.
Und er weist halt erstmal darauf hin, dass die Modifikation so die Annahme billiger ist als das Neubauen.
Das ist eine fundamentale These, die wir, glaube ich, bei uns in der IT haben.
Und ich würde die halt deutlich unterschreiben.
Ich fand es halt interessant, überhaupt die Frage zu stellen.
Also kann ich halt irgendwie Dinge komplett neu bauen.
Also er hatte dann geschrieben, dass eben Gebäude häufig komplett abgerissen und wieder neu aufgebaut werden.
Und in der Software gibt es halt, glaube ich, eher ein Trend dazu, Sachen halt irgendwie zu ändern.
Und nicht, die Dinge heißen ja auch Software.
Also Software, das bedeutet halt, es ist soft, es ist änderbar.
Und er sagt halt weiter, dass das der Annahme zugrunde liegt, dass halt der Text geändert werden muss, was irgendwie einfach ist.
Ich kann die Tasten down und es ist halt einfach tun.
Aber das widerspricht eben diese Theorie, diesem Ansatz, dieser Idee, dass das eigentlich eine Theoriebildung ist.
Dann ist irgendwie der Text zu ändern, noch die einfachste Sache, die einfachste Sache.
Man wird vielleicht eine gewisse Flexibilität einbauen.
Und diese Flexibilität, die ich halt einbaue, ich kann ja zum Beispiel auch Sachen konfigurieren, nicht, dass ich irgendwie sage, es gibt ein Datumsformat und das kann ich konfigurieren.
Dann ist das irgendwie trivial, also nahezu trivial änderbar.
Und das wird aber irgendwann teuer.
Wenn ich halt versuche, alle möglichen Änderungen dort irgendwie reinzubekommen, dann wird es halt irgendwie teuer und schwierig.
So, und jetzt sagt er eben, ich muss also entscheiden, wie ähnlich die neuen Anforderungen gegenüber den Umgesetzten sind.
Dafür brauche ich eine Theorie dafür, wie das System funktioniert.
Nur anhand dessen kann ich diese Ähnlichkeit irgendwie feststellen.
Das kann ich nicht trivial irgendwie durch Regeln ermitteln.
Also ich kann jetzt nicht sagen, okay, hier ist eine Änderung zu seiner Aussage, hier ist halt ein Programm.
Wie kompliziert ist das, das halt irgendwie hinzubekommen, mindestens nicht durch deterministische Regeln.
Und diese Theoriebildung, diese Theoriebildung kann also deswegen erklären, warum Source-Code über die Zeit schlechter wird.
Das ist auch etwas, was in den Case-Studies ja durchscheint.
Wenn Menschen den Code ändern, ohne dass sie die Theorie verstehen, dann wird das System komplizierter und am Ende eigentlich sogar zerstört.
Also die innere Struktur wird irgendwie zerstört.
Und das ist ja etwas, worunter halt Legacy-Systeme beispielsweise potenziell leiden.
So, dann kommt halt irgendwie die Aussage, naja, also Programmänderungen im Sinne der nach außen beobachbaren Eigenschaften, sind auf viele unterschiedliche Arten, können auch viele für unterschiedliche Arten vorgenommen werden.
Das heißt, wenn ich jetzt sage, das Programm soll eben für bestimmte Eingaben, für bestimmte Situationen sich anders verhalten, dann kann ich das auf sehr vielen unterschiedlichen Wegen implementieren.
Aber nur einige entsprechen eben dieser Theorie des Programms.
Und nur diese werden halt die Wartbarkeit erhalten.
Das ist also eigentlich die Herausforderung, die ich da halt habe.
So, und er hat dann ein Kapitel über das Leben, also Programm Life, Death and Revival.
Also das Leben meines Programms, der Tod und die Wiederweckung.
Das heißt, was er dort im Prinzip sagt, wenn ich also ein Programm entwickle, ein Programm baue, dann entwickelt das Team der ProgrammiererInnen irgendwie eine Theorie.
Und während das Programm lebt, hat dieses Team, das die Theorie des Programms hat, die Kontrolle über das Programm.
Und wenn das Team aufgelöst wird, stirbt das Programm.
And damit stellt er im Prinzip in Uprede, dass überhaupt irgendjemand anders jemals sinnvoll Software modifizieren kann, die von einer bestimmten Team zusammengebaut worden ist.
Er sagt dann, wenn ich neue Menschen hinzufügen will, also neue ProgrammiererInnen haben möchte, dann müssen die mit den Mitgliedern des Teams eng zusammenarbeiten, praktisch unter Aufsicht und er zieht die Parallele zu dem Erlernen eines Instruments.
Also wenn ich jetzt irgendwie ein Instrument lernen will, dann ist der klassische Weg, den wir kennen, dass irgendjemand mir das zeigt.
Und das ist wahrscheinlich nicht so wahnsinnig erfolgreich, wenn ich halt versuche, das aus dem Buch zu lernen oder sowas nicht.
Und das ist halt, glaube ich, da der Ansatz.
Wichtig dabei für ihn: Es gibt dann Diskussionen über das Programm, es gibt Diskussionen über den Impact auf die reale Welt.
And that bedeutet halt wiederum, dass es eben unmöglich ist, die Theorie aus der Dokumentation zu entnehmen.
Und dafür hat er ja relativ gute Hinweise.
Er hat nämlich den Hinweis, dass in diesen beiden Case Studies, die er halt gehabt hat, offensichtlich Dokumentation existiert.
Die Information ist da sogar drin, aber es hilft halt nicht.
Und das bedeutet, also sicher sind da halt irgendwo Teile dieser Theorie.
Und er sagt halt weiter, dass man möglicherweise einem Team die Möglichkeit geben soll, das Problem erneut zu lösen, statt irgendwie die Software zu übernehmen.
Also das ist so ein bisschen dieses Abbrechen sozusagen.
Dann schreibt er halt noch was über die Methoden.
Methoden ist etwas, also ich habe das Gefühl, das ist halt etwas, was so ein bisschen oldschoolig ist.
Also, glaube ich, so der Zeit geschuldet ist.
Darunter versteht man ein Vorgehen, was irgendwie dazu führt, dass man halt sozusagen unausweichlich auf jeden Fall erfolgreich ein Programm entwickeln kann.
Und was halt irgendwie mit einer bestimmten Abfolge von Schritten erstellt wird.
Und was er jetzt irgendwie sagt, ist halt, dass es eben nicht die richtige Methode geben kann.
Er behauptet, dass es aber bei einer wissenschaftlichen Erkenntnis, was ja auch Theoriebildung ist, sowas auch nicht gibt.
Ich habe irgendwo auch mal bei Social Media so ein Ding gesehen, nicht, wo halt im Prinzip steht, also wo halt aufgezeigt wird, wie chaotisch der Weg ist, bis ich halt irgendwie mal was in einem Paper habe und das halt mal dokumentiert habe als Wissenschaftlerin.
Und es gibt allerdings Mechanismen, um Denken anzureden, zum Beispiel bei MathematikerInnen, das hilft zwar, es ist aber keine Methode, und er verweist da auch tatsächlich auf ein Paper von der Christiane Floyd von damals.
Das heißt also, es gibt irgendwie kein Vorgehen mit bestimmten Schritten, das da wirklich hilft.
So, und das, dann hat er ja noch The Programmer Status and the Theory Building View, also der Status eines Programmierers und diese Theoriebildung, was hat das für eine Aussage.
Und da sagte er halt, man kann Software eben nicht industriell fertigen aus diesem Grund.
So.
Genau, jetzt ist ja die, also soweit sozusagen der Inhalt des Papers im Wesentlichen zügen.
Jetzt ist die Frage: Was machen wir da draus?
Also die erste Frage ist halt, stimmt das überhaupt?
Also kann ja nicht, also nur weil Peter Nauer irgendwie ein Paper aufschreibt, bedeutet es ja noch lange nicht, dass das halt die Realität ist.
Und man kann eben, es kann, dass er eben sagt, naja, das sind nur Anekdoten, er hat halt keine echte Empirik.
Das heißt, man könnte jetzt, wenn man sozusagen strenge wissenschaftliche Parameter ansetzt, irgendwie sagen, das Paper hat halt das Potenzial, das halt schlicht nicht stimmt.
Ich bin nicht sicher, ob das sozusagen die richtige Frage ist.
Also ich glaube, das ist halt ein Gedankenmodell, mit dem man halt versuchen kann, Situationen, auf die man halt stößt zu erklären und daraus Schlüsse zu ziehen und dafür zu sorgen, dass man halt in der Realität irgendwie besser davor steht.
Und das muss man für sich entscheiden, ob man das halt sozusagen tut.
Ich bin nicht sicher, ob diese Empirik dafür eine Ausschlag geben wäre.
Es gibt dann so ein paar Themen, also diese Geschichte mit der Auswirkungen auf die Realität, in die Diskussion sind wir ja gerade eben schon so ein bisschen gekommen.
Ich habe halt das Gefühl, dass halt einige Systeme von den Auswirkungen in der realen Welt relativ weit entfernt sind.
Und da war irgendwie schon die Diskussion mit Christian.
Also reale Welt bedeutet für mich physische Dinge außerhalb des Rechners.
Ein Compiler ist halt inhärent etwas, was sozusagen nur im Rechner wirkt.
Der Grund, und das war das, worauf ich sozusagen vorhin nicht so tief eingehen wollte, ich bin halt grundsätzlich der Meinung, dass halt Softwareentwicklung bedeutet, dass halt Menschen für Menschen Software entwickeln.
Und bei diesem Compiler kann man das, glaube ich, sehr gut sehen.
Da gibt es halt irgendwelche Menschen, die wollen, dass dieser Compiler gebaut wird.
Entwickler gehören zum Beispiel dazu, stakeholder gehören halt dazu, die jetzt irgendwie sagen, sie wollen halt irgendwie auf dieser Plattform irgendwas bauen und halt brauchen dafür irgendwie dieses Werkzeug.
Und das ist halt die Ebene, auf der ich das eher sehen würde.
Ich würde halt behaupten, dass halt EntwicklerInnen für irgendwelche Menschen Software entwickeln oder ProgrammiererInnen für irgendwelche Menschen Software entwickeln.
Und dass das sozusagen die Grundlage ist, aber das ist so ein bisschen Detail.
Auf jeden Fall kaufe ich halt, dass es irgendwelche Menschen gibt, die besser darstellen können, wie das System funktioniert und das halt eher verstehen.
Ich finde mich da also tatsächlich wieder.
Ich finde, das ist ein guter Ansatz, um halt zu verstehen, wie Softwareentwicklung funktioniert.
And für mich ist es halt eine gute Erklärung für so einige Sachen, die wir halt haben.
Also, zum Beispiel entwickeln wir ja Software in Iteration.
Ich glaube, das ist halt deswegen, weil wir halt diese Theorie aufbauen müssen, die halt verfeinern müssen und halt in jedem Schritt irgendwie da besser werden.
Und das findet sich halt auch im Code wieder, and we won't den Code halt sozusagen jeweils dem aktuellen Stand der Theorie anpassen.
Und das passt ja auch zu dem wissenschaftlichen Progress, nicht.
Also, wir haben irgendwann Newton showing Mechanik gehabt, dann haben wir halt irgendwann verstanden, oops, this is halt irgendwie nicht ausreichend.
And so haben wir dann eine neue Theorie gebaut, and this is, glaube ich, bei Softwareentwicklung eine ähnliche Geschichte.
Diese Probleme herauszufinden, wie alte Systeme funktionieren, das finde ich da und die Entstehung von Legacy, das finde ich total nachvollziehbar, dass eben Legacy schwierig wird, also dann insbesondere kaputt geht, wenn man es halt anderen Menschen gibt, die halt irgendwie nicht verstanden haben, warum das so ist und wie das halt funktioniert.
Ich habe selber eine Episode gemacht, die verlinke ich irgendwie auch nochmal darüber, dass er irgendwie Entwicklung lernen ist.
Das passt da, glaube ich, auch sehr gut dazu.
Und es bedeutet halt, dass ein Handover immer ein Problem sein wird, weil ich eben Menschen diese Theorie klar machen muss.
Und das ist eben aufwendig und schwierig, weswegen irgendwie Teamstabilität eben ein hohes Gut ist.
Und auch da finde ich mich halt wieder.
Ich bin nicht, also eine Sache, bei der ich mir nicht so sicher bin, ob die halt dadurch erklärt wird, ist, wenn sich also jetzt jemand hinstellt, der nicht Softwareentwicklung verstanden hat und da sozusagen formal eine Ausbildung hat oder eben nicht ausreichend Praxiserfahrung hat.
Die bauen halt Software, die halt leicht außer Kontrolle gerät.
Habe ich irgendwie auch schon gemacht, hat, glaube ich, jeder schon mal gemacht.
Jeder fängt halt irgendwie mal an.
Und ich glaube, dass es da irgendwie nicht erklärt.
Also, warum habe ich ein System, was schwer wartbar ist, was halt niemand versteht, potenziell deswegen, weil halt Leute es gebaut haben, die halt einfach bestimmte Konzepte nicht verstehen, weswegen ich eben glaube, dass Menschen, also für mich ist das prototypische Beispiel halt ein Exospreadsheet, wo ich dann halt irgendwann Makros auch reinsetzt oder Basic for Applications, das sind Dinge, die halt nicht EntwicklerInnen bauen, die dann vielleicht außer Kontrolle geraten, die dann EntwicklerInnen ablösen.
Und ich glaube, das Problem ist nicht Excel, sondern ich glaube, da fehlt irgendwie ein Skill.
Und das ist, glaube ich, nicht diese Theorie, sondern dass es irgendwie nicht, wie entwickel ich sozusagen Software auf dieser Ebene.
Genau, der Christian Beutemüller hat halt geschrieben, das halte ich für eine steile These, die übernommen von Software benötigt Zeit, aber es ist durchaus möglich.
Gute Teams schaffen das mit Unterstützung in drei bis sechs Monaten.
Ja, ich finde halt auch, dass das, was der Peter Nauer dort schreibt, vielleicht ein bisschen übertrieben ist.
Auf der anderen Seite glaube ich halt, dass die Idee, dass man es halt übernimmt, einfach durch Dokumentation lesen, keine gute Idee ist.
Und ich würde jetzt irgendwie daraus ableiten, dass man halt die Menschen zusammenlegen, zusammenarbeiten lassen sollte, damit sie irgendwie die Software übernehmen und dass das halt produktiv ist.
Und insbesondere ist es halt so, dass ich für mich daraus ableiten würde, dass eben Dokumentation zwar hilft, aber es ist eben nicht das zentrale Ding.
Und das, was ich jetzt irgendwie die letzten Tage tatsächlich beim Kunden irgendwie auch gepredigt habe, ist eben, also schreibt halt eine Dokumentation, aber das Schreiben der Dokumentation ist auch ein Thema, weil man dabei die Sachen irgendwie nochmal durchdenken.
Und ich habe diverse Bücher geschrieben.
Da ist auch so, dass man eben beim Schreiben der Bücher das nochmal durchdenkt.
Und das ist, glaube ich, eine hilfreiche Aktion.
Und insgesamt, dazu wollte ich eigentlich später nochmal kommen, ich finde das halt nicht überraschend.
Also, wenn ich jetzt in einem Team bin und ich mache jeden Tag ein Stand-up, ich rede halt jeden Tag mit irgendwelchen Kolleginnen und mache halt irgendetwas, dann werde ich halt eine andere Art von Wissen haben, als wenn ich halt irgendwie eine Dokumentation durchlese und das ist halt dort ein Thema.
Genau, bedeutet halt, dass Schreiben tatsächlich Denken ist, wie Hugh Jürgen Call gerade sagt.
Das würde ich halt auch so sehen.
So, dann schreibt irgendein Link, ein LinkedIn-User, der anonym, der oder die Anonym ist, wenn man ein Musikinstrument nur von einer Person beigebracht bekommen kann, kann diese Rolle bei Software auch eine KI übernehmen.
Ich erzähle gleich was zu LLMs.
Der wesentliche Punkt, genau, das kann ich eigentlich gleich sagen.
Ich habe ja eine Episode gemacht zu dem Thema KI Bullshit.
Und da ging es halt darum, dass eben ein LLM Text generiert ohne Rücksicht auf die Wahrheit und dass es eben kein Modell von Wahrheit hat.
Und das ist halt hier ein Impact, den das Ganze halt hat.
Der Impact ist halt, wenn diese Aussage richtig ist, dass also Programmieren, das Bilden eine Theorie ist, dann bedeutet das halt, dass ich mit LLMs nur bis zu einem gewissen Maße weiterkomme.
Also ich kann ein Programm vielleicht bauen, das halt die richtigen Ausgaben produziert aus den richtigen Eingaben.
Aber wenn halt keine Theorie hintersteckt, dann bin ich halt genau in dieser Situation, die wir halt zum Beispiel bei den Compiler besprochen haben.
Dann wird eben da etwas bei Entstehen am Ende, was eben keine vernünftige Theorie hat und irgendwie sozusagen chaotisch ist.
Und das ist, glaube ich, dort die, oder potenziell die Herausforderung.
Und für mich eben auch der Grund, also das ist ja die fundamentale Aussage dieses Papers, ist ja gerade, sagt ja der Titel, Programmieren ist eine Theorie, ist Theoriebildung.
Das bedeutet halt, Programmieren ist nicht das Generieren von Text.
Das ist das, was LLMs machen.
Und deswegen ist das halt relevant.
Muss man kurz schauen.
Genau, und damit sind wir halt bei diesem LLM-Thema insgesamt.
Also, das ist halt auch wieder, deswegen hätte ich halt nochmal Wert darauf gelegt zu sagen, Menschen entwickeln Software für Menschen.
Irgendjemand tut irgendetwas, was halt dazu führt, dass es ein ausführbares System gibt, meinetwegen mit dem LLM oder auch ohne.
Irgendjemand freut sich darüber, weil irgendwelche Business-Ziele halt erreichbar sind oder halt, die halt diese Software benutzen wollen für irgendwelche Ziele.
Das ist das, was Softwareentwicklung ist.
Und das bedeutet halt, dass man eben am Ende irgendwelche Menschen hat, die es bauen.
Und wenn die ja nicht verstehen, wie das System funktioniert, wird es halt irgendwann schwierig.
Und das ist halt sozusagen die grundsätzliche Idee.
Führt also zu der Frage, wie weit halt LMs kommen, ohne dass sie jetzt aus einem Modell haben.
Und mein Hinweis, also wäre halt einmal, ich würde halt LMs so benutzen, dass ich eben immer noch das mentale Modell von dem System habe, was also bedeutet, dass ich eben nicht, also das sowas wie Vibecoding, wo ich also unbeaufsichtigt das System bauen lasse, da eher nicht so gut ist und auf der Voraussetzung, dass eben Wartbarkeit und Erinnerbarkeit ein Thema ist.
Und es ist eben nochmal der Hinweis, dass halt das Produzieren von Code eben nicht das Problem ist.
Genau, Christian Beutmüller hat geschrieben, Working Software over comprehensive documentation, also nicht funktionierende Software ist wichtiger als ausführliche Dokumentation.
Who would have guessed?
Das hätte sich das halt gedacht, das ist aus dem IGM Manifest.
Das ist hier noch was anderes.
Also, der Grund, warum das für mich halt so wichtig ist, ist, ich habe halt subjektiv so ein paar Beratungskunden gehabt, die im Prinzip gesagt haben, nur eine Person kommt damit zurecht, diese Software halt irgendwie zu ändern oder nur ein Team.
Die sollen jetzt eine Dokumentation schreiben, dann ist das Problem gelöst.
Und das ist eben nach diesem Paper keine gute Idee, weil die Dokumentation halt nicht hilft.
Und das passt auch zu dem, was ich erwarten würde.
Wenn mir halt jemand sagt, hier ist halt ein großer Stapel Papier, hier ist halt die Software, viel Spaß.
Das wird halt schwierig.
Und ich finde halt diese Analogie mit dem Lernen eines Instruments gar nicht schlecht.
Also, ich kann mir jetzt ein Buch durchlesen darüber, wie man Geige spielt, dann kann ich es halt irgendwie versuchen.
Das wird vermutlich eine Vollkatastrophe.
Irgendwann wird es halt vielleicht besser, aber nicht.
Also, wenn mir jetzt jemand zeigt, ist es wahrscheinlich wirklich die bessere Idee.
So, mal kurz gucken.
Was steht da?
Also who you're gonna call.
Der Bezug zur Welt ist immer notwendig, um die Wahrheit und das Modell, beziehungsweise die Theorie zu finden.
Meiner Meinung nach sind LMs deswegen dazu nicht in der Lage kann, Bezug zur Umwelt.
Deine Meinung hatte ich gerade gesagt.
Nicht LMs können halt Code produzieren, unzweifelhaft.
Aber es wird eben, sie können halt nicht diese Theorie bauen.
Und das bedeutet halt, dass ich halt am Ende eben so verabe, die halt ja zumindest schwer erwartbar ist.
So, was hat Urs Enster geschrieben?
Wir können nicht unser gesamtes Wissen über ein Thema externalisieren, dokumentieren.
Es wird immer Lücken geben, ja, genau.
Und genau genommen ist es ja sogar so, dass man, wenn man, also wie soll ich sagen, ich bin jetzt auch kein Philosoph, aber was halt bei mir hängen geblieben ist, ist eben die Aussage, wenn ich halt irgendetwas sage, dann bedeutet das halt, dass ich versuche, sozusagen das, was in meinem Gehirn ist, jemandem anderen irgendwie klar zu machen.
Und das ist halt imperfekt.
Also das wird halt nicht eine perfekte Abbildung sein.
Und das Problem habe ich halt immer.
Also auch hier jetzt in dieser Episode, wenn ihr halt diese Episode seht oder hört, werdet ihr nicht genau dieselben Gedanken haben wie ich.
Das wäre halt auch irgendwie extrem überraschend.
Und das bedeutet halt, dass ich dort immer Kommunikationsverlust habe.
Und das ist halt irgendwie dieses Problem mit dieser Theorie.
Ja, ich habe mir noch aufgeschrieben, was ist denn diese Theorie?
Ein Punkt, Aspekt davon haben wir, glaube ich, schon genannt oder hatte ich schon genannt.
Ist das tatsächlich eine Theorie über die Welt?
Beim Compiler finde ich das halt schwierig, haben wir diskutiert, aber es ist halt schon etwas, was sozusagen eine Theorie darüber, was irgendwie der Wert ist, so wie das System halt funktioniert.
Am Ende ist halt irgendjemand glücklich und wir müssen halt koordinieren, wie wir gemeinsam an dem System arbeiten.
Dann ist halt die Frage, ist eine Architektur eine Theorie?
Wir sind ja bei Software-Architektur im Stream.
Also es ist irgendwie die Frage, ob halt eine Architektur die Theorie ist.
Das ist halt eher nicht der Fall.
Also die Aussage ist ja, dass es deutlich komplexer.
Und es ist ja insbesondere so, dass der Peter Nauer im Prinzip sagt, das ist nicht aufschreibbar.
Also die Aussage, die er trifft, ist, wenn ich halt es aufschreibe, also eine Dokumentation habe, ist das nicht ausreichend.
Es ist irgendwie mehr.
Und es ist so, also in der Version des Papers, die ich auch verlinken will werde, ist halt so ein so ein Kommentar am Ende, wo halt wer auch immer das Paper da halt irgendwie nochmal veröffentlicht hat, halt reingeschrieben hat.
Diese Metapher, die es bei sowas wie XP gibt, bei Extreme Programming.
Ich würde überhaupt, die gibt es auch bei Domain-Driven Design.
Das sei halt eine Theorie.
Also, da gibt es halt irgendwie diese Idee, dass man halt sagt, meine Software funktioniert so wie eine Fertigungsstraße.
Ich habe halt einen Auftrag und an den verschiedenen Stages von dem Auftrag werden halt Informationen für den Auftrag ergänzt, sowas zum Beispiel.
So, und das ist jetzt eben eine Metapher, die ist halt relativ kurz, die diskutiert das.
Und es gibt ja auch diese Patterns of Enterprise Application, Quatsch, diese Poserbücher, Patterns of Software Architecture, wo sowas drinsteht, nicht so ein Brightboard-Pattern, wo irgendwie alle Teile, was auf dem gemeinsamen, in gemeinsamen Datenspace sozusagen reingeben und dann halt alle Teile darauf reagieren können.
Hub and Spoke-Architektur, was auch immer.
Und das ist halt deutlich nicht diese Theorie, weil sie lässt sich ja gerade nicht aufschreiben, sondern ist deutlich komplexer.
Dokumentation ist ja scheinbar eine Lösung, hatte ich halt gesagt.
Ich würde also Dokumentation eher als Gedächtnisstütze sehen.
Also, wenn ich es halt aufschreibe, kann ich mich erinnern, was eigentlich gemeint ist.
Das ist halt hilfreich, aber die Theorie ist halt irgendwie was anderes.
Und ich weiß nicht, wie es euch geht, aber für mich ist das halt dann so ein bisschen eine etwas magische Sache.
Also, ich kann es nicht aufschreiben, es ist da, es ist halt Wissen.
Der Hinweis, dass halt eine gemeinsame Mitarbeit an dem System eine Lösung ist, finde ich nachvollziehbar.
Und das ist auch, glaube ich, sehr logisch.
Und ich hatte es schon gesagt: bei der Menge an Kommunikation, die halt rund um Software passiert, jeden Tag ein Stand-Up und zillige Meetings, ist es halt nicht erstaunlich, dass halt alles, also außer Mitarbeiten, halt irgendwie mit viel Informationsverlust behaftet ist und ich dann halt ein Problem habe.
Jetzt muss ich mal schauen.
Wenn man neu in ein Team kommt, könnten LLMs die Rolle eines Teammitglieds übernehmen und die Software erklären, gute Frage.
Ich wäre pessimistisch, weil die Dinge halt ein ganzes Kontext Window haben.
Das heißt, sie können nicht die Software als Ganzes erfassen.
Und die, also wie soll ich sagen?
Das ist ja gerade die Aussage, dass das halt so eine nicht greifbare Theorie ist.
Also, eigentlich reden wir darüber, dass wir halt ein Modell haben, was halt irgendwie wegabstriert vom konkreten Code, was halt die Konzepte dahinter definiert.
Eine LLM generiert Text, das denkt nicht.
Das baut insbesondere keine Theorien.
In dem Sinne kann also ein LLM dann wahrscheinlich nicht wirklich so etwas erklären.
Das Problem dabei ist, wenn ich jetzt irgendwie einem LLM sage, erklär mir doch mal das System, generiert es halt ein Text, der hat scheinbar das System erklärt.
Und insofern kann das halt das tun.
Aber diese nicht, also ich stelle damit am Ende in Abrede, dass halt Softwareentwicklung bedeutet, dass Menschen für Menschen Software entwickeln.
Das bedeutet nämlich, dass ich eigentlich sage, also die Menschen, die das entwickeln, können sie zumindest teilweise durch LLMs ersetzen.
Und das ist halt relativ mutig.
Genau, hier steht: Das ist das Gedankenexperiment mit Maries Zimmer gibt.
Ich muss sagen, ich kenne das nicht, was halt irgendwie ähnlich ist.
Dann dieser Tod von Software, den er halt beschreibt, dort ist ja die Aussage, dass an der Stelle, wo sich halt das Team auflöst, die Software sozusagen tot ist.
Und ich finde das ehrlich gesagt schwierig.
Denn er sagt ja gleichzeitig, dass man halt Theorien vermitteln, erlernen und anwenden kann, zum Beispiel durch Mitarbeit.
Und er sagt ja nur, dass man das nicht ernsthaft durch Dokumentation kann.
Und das, also wie soll ich sagen, wenn es halt wirklich so ist, dass halt Software an einen Team gebunden ist und nur das Team es halt weiterentwickeln kann, das ist ein bisschen krass.
Ich glaube halt, dass dieses Handover halt natürlich eine Herausforderung ist.
Und ich würde halt ein explizites Handover machen und ich würde halt versuchen, durch Pair Programming solche Maßnahmen, halt diese Mitarbeit zu bekommen, über die er halt redet.
Aber ich glaube halt schon, dass man es im Prinzip einem anderen Team übergeben kann.
Und ich bin halt irgendwie auch nicht sicher, dass ja das, was er halt irgendwie gesagt hat, lasst doch das neue Team sozusagen das Problem nochmal neu lösen.
Das finde ich halt einmal deswegen schwierig, weil das halt wahnsinnig aufwendig ist.
Ich finde es auch deswegen schwierig, weil das Verständnis für Legacy-Systeme ist ja eben schwierig.
Das bedeutet, wenn ich jetzt anfange, das nochmal neu zu bauen, komplett from scratch, dann bedeutet das halt, dass ich ein großes System bauen muss, ein kompliziertes System, dass es halt aufwendig und eben nicht unbedingt in einer kurzen Zeit machbar.
Und dadurch ist irgendwie nicht die Aussage, wenn die das halt irgendwie neu bauen, das ist vielleicht die einfache Alternative.
Ich bin mir da halt nicht sicher.
Und die andere Sache ist eben, also dieser Tod des Systems, also das Paper sagt ja selber und gibt ja auch das Beispiel von diesem Compiler, wo halt am Ende eine Gruppe dran gearbeitet hat, die eben mit der Originalgruppe nichts mehr zu tun hat.
Und das hat ja funktioniert.
Das einzige Problem ist halt, dass das, was diese Gruppe halt irgendwie gebaut, halt suboptimal ist.
Okay, das mag halt sein, aber wenn das eben die einzige Wahl ist, dass ich halt suboptimal irgendwie Software entwickelt, dann werde ich das wohl tun müssen.
Und deswegen finde ich halt diesen Tod des Systems ein bisschen übertrieben an der Stelle.
Jetzt muss ich nochmal schauen.
Nils Alberti schreibt, Menschen erlernen Theorie in den unterschiedlichsten Feldern.
Sie lesen zum Beispiel Bücher, die sie ausgehend vom Big Picture systematisch in die einzelnen Stränge führt.
In der T haben wir nie eine vergleichbare Form für die systematische Dokumentation eines Systems als Theoriesystem entwickelt.
Eine solche Dokumentation würde neuen Entwicklern das Erfassen des Systems in seinem Gesamtsusammenhang ermöglichen.
Ja, stimmt, aber das, was er, was der Nauer ja sagt, ist, dass die Dokumentationsmöglichkeiten, die ihm halt zum damaligen Zeitpunkt zur Verfügung gestanden haben, das eben nicht leisten.
So, und jetzt können wir uns halt Softwareentwicklung im Jahr 2026 angucken.
Also da gibt es ja so etwas wie Act 42, das C4-Modell, viele, viele weitere Möglichkeiten, Architecture Decision Records oder so.
Und ich würde halt tatsächlich behaupten, dass keins, oder ich wäre sie, nein, ich würde behaupten, dass keiner dieser Ansätze so ist, dass er tatsächlich ermöglicht, dass sich dieses System eben ändern kann, nur anhand der Dokumentation.
Und im Übrigen weiß ich auch gar nicht, also wie soll ich sagen, warum sollte das ein Ziel sein?
Also gehen wir nochmal, also gehen wir nochmal von diesem prototypischen Fall aus, von dem ich halt das Gefühl habe, dass er bei mir am Consulting eine Rolle spielt.
Das heißt, die Aussage ist folgende.
Ich habe also ein Team, dieses Team kann die Software bauen.
Ich habe und aus irgendwelchen Gründen bin ich jetzt damit unzufrieden.
Ich möchte also zum Beispiel neue MitarbeiterInnen haben, ich möchte das vielleicht am anderen Team übergeben, was auch immer.
Lösungsvorschlag, Dokumentation schreiben.
Mein Lösungsvorschlag wäre, lass sie halt irgendwie zusammenarbeiten.
Pair Programming, Mob-Programming, whatever.
Und dann wird sich das Wissen und diese Theorie eben defundieren hin zu den neuen Mitgliedern des Teams.
Und das ist das, was der Nauer ja auch sagt.
Also, wenn die, also nicht, das könnte man ja jetzt so machen, dass man irgendwie sagt, okay, wir machen halt ein Ensemble oder einen Mob oder wir machen halt einen Pair und die Person, die halt neu ist im Team, setze sie halt in die Tastatur und macht es halt.
Und die macht es halt nur, wenn sie es halt echt verstanden hat.
So und das wird halt dazu führen, dass diese Person halt irgendwann das System auf dich verstanden hat.
So und jetzt ist irgendwie die Frage, ist das ein effektiverer und effizienter, also ist das ein effektiverer Weg.
Ich würde überhaupt ein Ja.
Das wäre meine Erwartungshaltung, nicht, aber das müsste man ausprobieren.
Und dann wäre die andere Frage, ist das effizienter, also ist das weniger teuer.
Das Schreiben von echt guter Dokumentation ist teuer und aufwendig.
Ich finde es nicht offensichtlich, dass das der billigere Weg ist.
Und dann ist eben die Frage, wie ich, also ob ich halt die Latte für Dokumentation so hochlegen will.
Man muss dann halt hinzufügen, nicht Dokumentation macht total viel Sinn.
Es hat Vorteile, also ich frage halt immer bei Architekturreviews nach der Dokumentation, weil es ist easy für den Auftraggeber, die Dokumentation mir einfach zu geben.
Das ist eine E-Mail.
Wir packen, da wird irgendwas eingepackt und dann kriege ich es halt irgendwie geschickt.
Aufwand, zehn Minuten.
Fünf.
Ich kann es mir irgendwie durchlesen und ich bin halt auf jeden Fall in einer besseren Position als ohne die Dokumentation.
Ich bin gleichzeitig absolut sicher, dass wesentliche Herausforderungen in dem Projekt und wesentliche Themen nicht in der Dokumentation stehen.
Deswegen bin ich ja Berater, um irgendwie nicht die richtigen Fragen zu stellen, um irgendwie zu sagen, da sind übrigens Blind Spots, das sind Themen, die halt irgendwie nicht in der Dokumentation stehen.
Und ich finde das jetzt auch nicht dramatisch.
Also nicht, das zeigt halt den Wert, meiner Ansicht nach von Dokumentation.
Nämlich, dass sie trivial reproduzierbar ist und man sie halt deswegen jemandem geben kann, aber es ist eben ein reduzierter Informationsumfang.
So, dann schreibt Christian Beuthenmüller, es gibt natürlich auch gute Theorien in der Software betrifft, aber halt nur Systeme, die sicherheitskritisch sind.
Echtzeitsysteme und Autos sind zum Beispiel beispielsweise formal spezifiziert.
Das ist aber nicht die Ebene, über die wir reden.
Also eine formale Spezifikation sorgt eben dafür, dass das System sicher die Anforderungen einhält.
Also weil ich das halt versuche, über formale Methoden, so ähnlich wie mathematische Beweise halt irgendwie nachzuweisen.
Diese Theorie, über die wir sprechen, hat aber eben im Wesentlichen die Funktion dafür zu sorgen, dass sich dieses System halt erweitern kann.
Und das ist ja das, was den Nauer halt sagt, wenn ich halt ein System habe, was halt irgendwelche Ausgaben produziert, also eben beispielsweise formal korrekt ist, dann gibt es ganz viele Möglichkeiten, das zu strukturieren.
Wie strukturiere ich das System?
Wie ändere ich das System anschließend?
Das ist halt diese Theorie und das ist da sozusagen der Punkt, um den es geht.
Ich bin auch ehrlich, ich bin mir nicht sicher, ob dieser Theoriebegriff halt ein guter ist.
Also eigentlich wirkt das auf mich eher wie so wie, ja, weiß ich nicht, die Gesamtmenge des Designs oder wie auch immer man das halt nennen will.
Und genau, Christian Woldenmüller schreibt halt weiter, dass es erfordert sehr viel Disziplin und ist sehr teuer.
Eben wegen der Sicherheitsanforderung, ja, aber nicht, dass es halt ein anderes Thema.
Ich würde halt behaupten, ich kann oder ich nehme an, dass ich formal verifizierte Systeme bauen kann, die ja man nicht versteht.
Und ich kann formal verifizierte, oder die halt andersrum.
Wenn ich ein formal verifiziertes System habe und ich habe halt Dokumentation und man sagt, mir halt, erweitere das mal bitte oder nicht, irgendjemandem von euch, würde ich nicht ausschließen, sondern eher davon ausgehen, dass das dazu führt, dass die Ideen hinter dem System und die Art und Weise, wie es halt aufgebaut ist, zerstört wird.
So, dann schreibt Ruyo-Gone-Call, ich kann DDD doch auch in Funktionalitäten denken, also im Boxen entspricht das dem Theoriebegriff.
Nein.
Also, das ist eine Architektur, das ist eine Aufteilung des Systems.
Und wir haben ja gerade, also jede Architekturdokumentation wird halt so eine Aufteilung des Systems in irgendwelche Boxennamen.
Wir haben gerade diskutiert und das wird sicherlich auch 85 der Fall gewesen sein.
Wir haben gerade diskutiert, dass das eben völlig unzureichend ist.
Und das ist vielleicht so ein bisschen, also wäre halt mein größtes Problem damit.
Ich finde das halt wolkig, nicht.
Also, das ist halt irgendwie, also das ist ja das, was im Prinzip der Peter Nauer sagt.
Es ist halt eben nicht so richtig greifbar.
Und also, das ist ja die innere, die die Aussage nicht.
Es gibt halt irgendetwas, was halt dieses Team weiß, was nicht so einfach aufschreibbar ist und dadurch erst können die halt das System wirklich ändern.
Und ich finde Theorie als Begriff halt auch schwierig.
Ich glaube, das ist, oder ich würde hoffen, mir wünschen, dass man es irgendwie anders nennt.
Es ist halt irgendwie ein tiefes Verständnis des Systems und nicht so sehr, ich finde halt diesen Impact zur realen Welt, den finde ich halt nicht so offensichtlich.
Achso, ich sollte nochmal schauen.
Nee, im Chat gibt es sonst, glaube ich, nichts, was ich noch diskutieren wollen würde.
Es gab eben die und im Formular bei Software-Tectoon-Stream auch nicht.
Dann würde ich erstmal sagen, vielen Dank für die Aufmerksamkeit.
Vielen Dank für die vielen Diskussionen, hat mich sehr gefreut.
Also ehrlich gesagt, ja, jetzt nicht so ein sozusagen Mainstream-Thema, würde ich jetzt mal unterstellen.
Und da freut es mich dann immer besonders, wenn es halt eine so rege Beteiligung gibt.
Ausblick, wir werden also nächste Woche sehr sicher keine Episode haben.
In der Woche drauf wird es dann zwei Episoden live geben von der Edge-Mids Architecture.
Und da, genau, könnt ihr sozusagen gespannt sein, wird es ja dann auf der Webseite stehen.
So, der Christian Beutmüller schreibt, dann die drastische Frage, gibt es einen wirklich einen Unterschied zwischen der Theorie und dem gesamten Code.
Ja, ich kann jemandem den Code auf den Tisch legen, haben sie ja gemacht, also bei dem Compiler.
Und die haben halt die Theorie nicht, weil wenn sie versuchen, den Code zu ändern, machen sie halt Änderungen, die halt die Theorie widersprechen und halt die Qualität des Systems halt reduzieren.
Und das ist halt da sozusagen das Problem.
Also, das ist was anderes.
Der Code ist nur etwas, was sich daraus ergibt, wie diese Theorie aussieht.
MK Linke 82 auf YouTube fragt, wäre der Begriff mentales Modell vielleicht geeignet als Theorie.
Ja, vielleicht.
Vielleicht ist der auch gar nicht schlecht.
Das, ja, also wäre halt auch eine Alternative.
Ich finde das halt bei den Begrifflichkeiten immer schwierig.
Eigentlich ist es halt bei solchen Papern halt so, dass der Peter Nauer in diesem Fall halt ein Begriff einführt für etwas, was er beschreibt und definiert.
Und da ist der Name eigentlich egal.
Also er hätte es halt auch Gummibärchen oder so nennen können.
Nur Theorie ist halt näher dran.
Mentales Modell ist halt mir auch näher dran.
Die Kritik, die ich halt tatsächlich hätte, wäre, dass für mich das eben nicht ein Modell dessen ist, wie der Impact der Software auf die reale Welt ist, sondern es ist halt eher so etwas Architektonisches, Designmäßiges, aber irgendwie nicht größer.
Also vielleicht wäre halt die, also man könnte halt auch sagen, wenn man wirklich das gesamte Design einer Software verstehen will, die Designkonzepte, das lässt sich nicht aufschreiben.
Und diese Designkonzepte, das ist halt das, worüber meiner Ansicht nach eher redet oder wie ich das halt eher sehen würde.
Gut.
Dann würde ich sagen, vielen Dank, schönes Wochenende.
Und vielen Dank, wie gesagt, auch für die Diskussion.
Und ich hoffe, dass man sich dann irgendwo wieder sieht.
Entweder in der realen Welt, gerne ja auch im Stream oder sonst auf anderen Weg.
Bis dahin, vielen Dank und schönes Wochenende.