Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur 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 Naur von 1985, wo es eben um Programmierung als Theoriebildung geht.
Der ist so ein bisschen bekannter.
Einmal, weil er mit an der Backus-Naur-Form für die Syntax von Programmiersprachen gearbeitet hat.
Der ist an Algol 60 beteiligt gewesen, einer der ersten so strukturellen Programmiersprachen.
Und außerdem bei einem Mann von der Christiane Floyd, mit der wir auch schon mal eine Episode gemacht haben.
Er ist mittlerweile leider verstorben und die Episode mit der Christiane Floyd, Professor Christiane Floyd, verlinke ich auch nochmal.
Warum dieses Thema?
Gerade so angesichts dessen, dass es die Idee gibt, mit LDMs und AI Software zu entwickeln, habe ich das Gefühl, dass ein paar grundlegende Ideen davon, was eigentlich Softwareentwicklung ist, unklar sind.
Und da ist es sinnvoll, sich ein paar grundlegende Sachen nochmal anzuschauen.
Ralf hat auch darauf hingewiesen, also Ralf D.
Müller, mit dem wir den Stream machen, dass das vielleicht ein interessantes Paper ist und dass das irgendwie auch Auswirkungen auf die Softwareentwicklung mit der AI hat.
Und deswegen hatte ich halt gedacht, schaue ich mir das mal an.
Worum geht es in dem Paper?
Also das Paper heißt eben Programming is Theorybuilding.
Er sagt in der Intro, dass seiner Meinung nach die Programmierung eine Aktivität ist, bei der Programmiererinnen eine Theorie über die Realität entwickeln.
Das ist etwas, was aus seiner Sicht aus Beobachtung geboren ist.
Und warum er dieses Paper geschrieben hat, ist, weil wenn man nicht versteht, was man tut, kann man auch nicht die Herausforderungen verstehen, die sich daraus ergeben und man kann sie 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 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 halt nicht einen sehr sympathischen Teil von diesem Paper, dass er eben gesagt hat, naja, Programmierung ist eben nicht nur Codeproduktion, 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 sich ja auch bewusst war.
Ich weiß nicht, ob er den bewusst nicht gewählt hat, aber mich als Programmierung, als sozusagen die Tätigkeit zu wählen, fand ich jetzt erstmal gut.
Und er behauptet halt, dass Programmierung ist, dass ich irgendwas in der realen Welt in Verbindung mit der Manipulation von Symbolen durch einen Computer bringe.
Was also bedeutet, dass ich eben ein Programm schreibe, was ja 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 im Stream.
So in diese Richtung geht das.
Und seine weitere Aussage ist halt, wenn sich diese Tätigkeit ändert, also im Computer abgebildet oder unterstützt wird, dann muss ich eben auch das Programm ändern.
Was halt wiederum bedeutet, dass 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 Study ist halt ein Compiler.
Und zwar baut halt eine Gruppe A einen Compiler für einen Computer X.
Und dann soll eine Gruppe B einen 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.
Also es gibt zwei Änderungen.
Einmal nur einen Computer unterstützen oder einen anderen Computer unterstützen und zum anderen eine Erweiterung der Sprache hinbekommen.
Und die Gruppe B hat sich damit 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 den 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, hört mal zu, können wir den Compiler folgendermaßen ändern und Gruppe A sagt dann ja oder nein.
Und es stellt sich dabei heraus, dass die Gruppe B Erweiterungsvorschläge, die eben nicht die Vorkehrungen im Compiler verwenden, die dafür vorgesehen sind, diese Vorkehrungen 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 Naur 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 tatsächlich zu einem Problem führt.
Jetzt muss ich mal schauen, da ist ein Kommentar auf YouTube.
Who you gonna call?
Schreibt, Programmierer inbauen Wissen über die Welt auf.
Die Welt kann ein anderes Team sein.
Meinst du damit, ein Team ist immer eine Umwelt?
Ne, ich meine halt die Welt.
Also die Welt, in der das Programm irgendwie funktionieren soll und letztendlich eben das Problem, was eben das System lösen soll.
So, zweite Case Study ist ein Realtime 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 Anpassungen.
Und die, was Noah jetzt eben beschreibt, ist, dass er nennt sie, also ich habe es übersetzt mit Backbeseitigende 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, 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.
Was das 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, signifikant zu unterscheiden und haben deswegen da irgendwie eine Art von Herausforderung.
Der Christian Beuthenmüller 1295 bei YouTube sagt, ja klar, man wird immer Experte in der Domäne, in der man arbeitet.
Ja, stimmt.
Aber 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 Domäne Compiler, und der Impact auf die reale Welt ist ja auch nicht so einfach zu sehen.
Also ein Compiler ist tatsächlich eben ein Werkzeug, was EntwicklerInnen benutzen.
Und das hat höchst indirekte Auswirkungen auf die reale Welt.
Das ist was anderes, wenn ich halt bei dieser industriellen Produktion, ist es klar, das ist halt ein Ding, 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 Riles 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 der Rile 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 Rile offensichtlich zwischen Intelligentenverhalten.
Wenn ich also zum Beispiel fische oder grammatisch korrekt spreche, dann sind das eben Dinge, die halt intelligentes Verhalten darstellen.
Mit intellektuellem Verhalten, intellectual im amerikanisch-englischen Original, habe ich aber dann eine Theorie.
Und 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 aufgebaut wird.
Das gilt zum Beispiel auch für alltägliche Dinge wie Reiseplanung.
Das ist das, was im Paper als Beispiel genannt wird.
Ich nehme an, dass damit sowas gemeint ist wie, ich kriege halt irgendwann eine Idee davon, wie eine deutsche Bahn arbeitet.
Ich kriege vielleicht eine Idee davon, wie Flughäfen arbeiten.
Man 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 Promiersprache, 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 nachher nochmal später.
Zurück zu diesem Thema mit der Theorie.
Das bedeutet also, es muss einen Zusammenhang zwischen Realität und Theorie geben und der muss irgendwie klar sein.
Nur weil ich Newton’sche Mechanik verstehen habe, bedeutet das noch lange nicht, dass ich weiß, wie ich sie benutze.
Das heißt, ich kann damit zwar theoretisch berechnen, wie ein Ball fliegt oder bestimmte andere Dinge berechnen, aber ich muss eben verstehen, wie die Dinge angewendet und genutzt werden.
Die Aussage, die jetzt in dem Paper steht, ist, dass Programmierer eine Theorie entwickeln, wie bestimmte Elemente der Realität durch ein Programm abgewickelt und unterstützt werden sollen.
Seine Aussage ist, dass diese Theorie wichtiger ist als der Code, die Dokumentation oder die Spezifikation.
Sie ist das, was offensichtlich Menschen dazu befähigt, dieses System zu ändern und zu verstehen.
Er geht der Frage nach, wo genau diese Theorie wichtig ist.
Das ist wichtig, damit Programmierer verstehen, was der Bezug zwischen dem Programm und der realen Welt ist.
Zum Zweiten können Programmierer erklären, was jeder Teil des Programms ist und was er tut.
Da kann man natürlich sagen, es gibt Prinzipien.
Wir kennen alle verschiedene Design-Patterns.
Wir können über Microservices reden, Schichten oder was auch immer.
Das ist zwar so, aber wir müssen trotzdem, selbst wenn das System solche Prinzipien nutzt, ProgrammiererInnen wissen, welche genutzt werden.
Aus meiner Consulting-Erfahrung würde ich hinzufügen, häufig werden diese Prinzipien viel verstanden oder modifiziert.
Deswegen nützt es wenig, wenn man sagt, ich benutze eine hexagonale Architektur.
Oder wir machen Schichten oder Microservices.
Wenn man tiefer gräbt, stellt man fest, dass es komplizierter ist, dass es an bestimmten Stellen Verstöße gibt.
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, wenn ich eine Änderung machen will, wir hatten zum Beispiel das Beispiel, dass ich eine andere Programmiersprache unterstützen möchte und ein anderes Ziel für einen Compiler.
Da muss ich mir überlegen, wie ähnlich diese Sachen sind gegenüber dem, was ich umgesetzt habe.
Und wie ich das in diese Theorie und damit in das Programm einbaue. Ähnlichkeit ist etwas, was im hohen Maße subjektiv ist und tatsächlich wahnsinnig schwer zu klassifizieren ist.
Wie sind Dinge ähnlich?
Eine Maus ist ein Säugetier, genauso wie ein Wal.
Das ist in gewisser Weise ähnlich.
Wenn ich mir das Genom ansiehe, sind sie wahrscheinlich wahnsinnig ähnlich.
Aber natürlich ist das, wenn ich es mir anschaue, nicht so.
Das nächste Kapitel ist die Geschichte mit Problemen und Kosten von Programmänderungen.
Software wird modifiziert.
Das ist eine große Herausforderung.
Er weist erst einmal darauf hin, dass die Modifikation so die Annahme billiger ist als das Neubauen.
Das ist eine fundamentale These, die wir bei uns in der IT haben.
Ich würde die deutlich unterschreiben.
Ich fand es interessant, überhaupt die Frage zu stellen.
Kann ich Dinge komplett neu bauen?
Er hatte geschrieben, dass Gebäude häufig komplett abgerissen und wieder neu aufgebaut werden.
In der Software gibt es einen Trend dazu, Sachen zu ändern.
Die Dinge heißen ja auch Software.
Das bedeutet, es ist soft, es ist änderbar.
Er sagt weiter, dass der Text geändert werden muss, was einfach ist.
Ich kann das einfach tun.
Aber das widerspricht dieser Idee, dass das eine Theoriebildung ist.
Dann ist der Text, das zu ändern, die einfachste Sache.
Man wird vielleicht eine gewisse Flexibilität einbauen.
Diese Flexibilität, die ich einbaue, ich kann zum Beispiel auch Sachen konfigurieren.
Es gibt ein Datumsformat, das kann ich konfigurieren.
Dann ist das nahezu trivial änderbar.
Das wird aber irgendwann teuer.
Wenn ich versuche, alle möglichen Änderungen reinzubekommen, dann wird es teuer und schwierig.
Jetzt sagt er, ich muss entscheiden, wie ähnlich die neuen Anforderungen gegenüber den umgesetzten sind.
Dafür brauche ich eine Theorie, wie das System funktioniert.
Nur anhand dessen kann ich diese Ähnlichkeit feststellen.
Das kann ich nicht durch Regeln ermitteln.
Ich kann nicht sagen, hier ist eine Änderung zu seiner Aussage.
Hier ist ein Programm.
Wie kompliziert ist das, das hinzubekommen?
Mindestens nicht durch deterministische Regeln.
Diese Theoriebildung kann deswegen erklären, warum Source Code über die Zeit schlechter wird.
Das ist auch etwas, was in den Case-Studies durchscheint.
Wenn Menschen den Code ändern, ohne dass sie die Theorie verstehen, dann wird das System komplizierter und am Ende eigentlich sogar zerstört.
Die innere Struktur wird zerstört und das ist etwas, worunter Legacy-Systeme beispielsweise potenziell leiden.
Dann kommt die Aussage, die Programmänderungen im Sinne der nach außen beobachtbaren Eigenschaften können auch für unterschiedliche Arten vorgenommen werden.
Das heißt, wenn ich jetzt sage, das Programm soll 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 dieser Theorie des Programms und nur diese werden die Wartbarkeit erhalten.
Das ist also die Herausforderung, die ich da habe.
Er hat ein Kapitel über das Programm Life, Death and Revival, also das Leben eines Programms, der Tod und die Wiedererweckung.
Das heißt, was er dort im Prinzip sagt, wenn ich 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.
Damit stellt er im Prinzip in Abrede, dass überhaupt irgendjemand anders jemals sinnvoll Software modifizieren kann, die von einem 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.
Wenn ich jetzt ein Instrument lernen will, dann ist der klassische Weg, den wir kennen, dass irgendjemand mir das zeigt und es ist wahrscheinlich nicht so wahnsinnig erfolgreich, wenn ich halt versuche, das aus dem Buch zu lernen oder sowas.
Und das ist, 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 und das 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 gehabt hat, offensichtlich Dokumentation existiert.
Die Information ist da sogar drin, aber es hilft halt nicht.
Sicher sind da Teile dieser Theorie und er sagt weiter, dass man möglicherweise einem Team die Möglichkeit geben soll, das Problem erneut zu lösen, statt die Software zu übernehmen.
Also das ist so ein bisschen dieses Abbrechen sozusagen.
Dann schreibt er noch was über die Methoden.
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 bei einer wissenschaftlichen Erkenntnis, was ja auch Theoriebildung ist, sowas auch nicht gibt.
Ich habe auch mal bei Social Media so ein Ding gesehen, wo im Prinzip aufgezeigt wird, wie chaotisch der Weg ist, bis ich mal was in einem Paper habe und das mal dokumentiert habe als Wissenschaftler.
Es gibt allerdings Mechanismen, um Denken anzureden, zum Beispiel bei Mathematikern.
Das hilft zwar, ist aber keine Methode.
Und er verweist 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.
Dann hat er noch den Programmer Status and the Theory Building View, also der Status eines Programmierers und diese Theoriebildung.
Was hat das für eine Aussage?
Und da sagt er, man kann Software eben nicht industriell fertigen aus diesem Grund.
So weit sozusagen der Inhalt des Papers in wesentlichen Zügen.
Jetzt ist die Frage, was machen wir daraus?
Also die erste Frage ist, stimmt das überhaupt?
Nur weil Peter Naur ein Paper aufschreibt, bedeutet das ja noch lange nicht, dass das die Realität ist.
Es kann sein, dass er eben sagt, naja, das sind nur Anekdoten.
Er hat keine echte Empirik.
Das heißt, man könnte jetzt, wenn man sozusagen strenge wissenschaftliche Parameter ansetzt, irgendwie sagen, das Paper hat das Potenzial, das schlicht nicht stimmt.
Ich bin nicht sicher, ob das sozusagen die richtige Frage ist.
Ich glaube, das ist ein Gedankenmodell, mit dem man versuchen kann, Situationen, auf die man stößt, zu erklären und daraus Schlüsse zu ziehen und dafür zu sorgen, dass man in der Realität irgendwie besser davorsteht.
Das muss man für sich entscheiden, ob man das sozusagen tut.
Ich bin nicht sicher, ob diese Empirik dafür einen Ausschlag geben wäre.
Es gibt dann so ein paar Themen.
Also diese Geschichte mit der Auswirkung auf die Realität, in die Diskussion sind wir ja gerade eben schon ein bisschen gekommen.
Ich habe das Gefühl, dass einige Systeme von den Auswirkungen in der realen Welt relativ weit entfernt sind.
Da war schon die Diskussion mit Christian.
Reale Welt bedeutet für mich physische Dinge außerhalb des Rechners.
Ein Compiler ist inherent etwas, was nur im Rechner wirkt.
Der Grund, und das war das, worauf ich mich vorhin nicht so tief eingehen wollte, ich bin grundsätzlich der Meinung, dass Softwareentwicklung bedeutet, dass Menschen für Menschen Software entwickeln.
Und bei diesem Compiler kann man das, glaube ich, sehr gut sehen.
Da gibt es irgendwelche Menschen, die wollen, dass dieser Compiler gebaut wird.
EntwicklerInnen gehören zum Beispiel dazu, Stakeholder gehören dazu, die sagen, sie wollen auf dieser Plattform etwas bauen und brauchen dafür dieses Werkzeug.
Das ist die Ebene, auf der ich das eher sehen würde.
Ich würde behaupten, dass 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 ein bisschen Detail.
Auf jeden Fall kaufe ich, dass es irgendwelche Menschen gibt, die besser darstellen können, wie das System funktioniert und das eher verstehen.
Ich finde mich da tatsächlich wieder.
Ich finde, das ist ein guter Ansatz, um zu verstehen, wie Softwareentwicklung funktioniert.
Für mich ist es eine gute Erklärung für einige Sachen, die wir haben.
Zum Beispiel entwickeln wir Software in Iterationen.
Ich glaube, das ist deswegen, weil wir diese Theorie aufbauen müssen, die wir verfeinern müssen und in jedem Schritt wieder besser werden.
Das findet sich auch im Code wieder.
Wir werden den Code jeweils dem aktuellen Stand der Theorie anpassen.
Das passt auch zu dem wissenschaftlichen Progress.
Also wir haben irgendwann eine newtonische Mechanik gehabt.
Da haben wir irgendwann verstanden, ups, das ist nicht ausreichend.
Und so haben wir dann eine neue Theorie gebaut.
Und das ist, 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 Legacy schwierig wird, also dann insbesondere kaputt geht, wenn man es anderen Menschen gibt, die nicht verstanden haben, warum das so ist und wie das halt funktioniert.
Ich habe selber eine Episode gemacht, die verlinke ich nochmal darüber, dass Entwicklung Lernen ist.
Das passt da, glaube ich, auch sehr gut dazu.
Und es bedeutet, 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 Teamstabilität ein hohes Gut ist.
Und auch da finde ich mich wieder.
Eine Sache, bei der ich mir nicht so sicher bin, ob die halt dadurch erklärt wird, ist, wenn sich 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 leicht außer Kontrolle gerät.
Das habe ich auch schon gemacht.
Das hat, glaube ich, jeder schon mal gemacht.
Jeder fängt halt irgendwie mal an.
Und ich glaube, das ist da eben nicht erklärt.
Warum habe ich ein System, das schwer wartbar ist, was dann jemand versteht?
Potenziell deswegen, weil 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 ein Excel-Spreadsheet, wo ich dann halt irgendwann Makros auch reinsetze oder Basics für 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 das ist irgendwie nicht, wie entwickle ich sozusagen Software, aber auf dieser Ebene.
Genau, der Christian Beuthenbüller hat geschrieben, das halte ich für eine steile These.
Die Übernahme von Software benötigt Zeit, aber 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 Naur dort schreibt, vielleicht ein bisschen übertrieben ist.
Auf der anderen Seite glaube ich halt, dass die Idee, dass man Zeit ü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 durchdenkt.
Ich habe diverse Bücher geschrieben.
Da ist es 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 Julio Gonacall gerade sagt.
Das würde ich halt auch so sehen.
So, dann schreibt ein LinkedIn-User, der 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, ist 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 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 da keine Theorie hinter steckt, dann bin ich halt genau in dieser Situation, die wir zum Beispiel bei dem 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.
Mal kurz schauen.
Genau und damit sind wir halt bei diesem LLM Thema insgesamt.
Also das 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 einem LLM oder auch ohne.
Irgendjemand freut sich darüber, weil irgendwelche Businessziele halt erreichbar sind oder 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 sozusagen die grundsätzliche Idee.
Führt also zu der Frage, wie weit LLMs kommen, ohne dass sie ein Modell haben.
Und mein Hinweis wäre halt einmal, ich würde LLMs so benutzen, dass ich eben immer noch das mentale Modell von dem System habe, was also bedeutet, dass ich eben nicht, also sowas wie Webcoding, wo ich also unbeaufsichtigt das System bauen lasse, da er nicht so gut ist und auf der Voraussetzung, dass eben Wartbarkeit und Erinnerbarkeit ein Thema ist.
Und das ist eben nochmal der Hinweis, dass halt das Produzieren von Code eben nicht das Problem ist.
Genau, Christian Beuthmüller hat geschrieben, Working Software over Comprehensive Documentation, also nicht funktionierende Software ist wichtiger als ausführliche Dokumentation.
Who would have guessed?
Wer hätte sich das gedacht?
Das ist aus dem IKEA Manifest.
Das ist hier noch was anderes.
Also der Grund, warum das für mich so wichtig ist, ich habe halt subjektiv so ein paar Beratungskunden gehabt, die im Prinzip gesagt haben, nur eine Person kommt damit zurecht, diese Software 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 jemand sagt, hier ist ein großer Stapel Papier, hier ist die Software, viel Spaß, das wird halt schwierig.
Und ich finde 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, das ist wahrscheinlich wirklich die bessere Idee.
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.
Kein Bezug zur Umwelt.
Deine Meinung hatte ich gerade gesagt.
LMS können Kot produzieren, unzweifelhaft, aber sie können halt nicht diese Theorie bauen.
Und das bedeutet, dass sie halt am Ende eben zur Färbe, die halt zumindest schwer wartbar ist.
Was hat Urs Enzler 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 bei mir hängen geblieben ist, ist eben die Aussage, wenn ich halt irgendwas sage, dann bedeutet das halt, dass ich versuche, das, was in meinem Gehirn ist, jemandem anderen irgendwie klarzumachen.
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 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, 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 ist irgendwie die Frage, ob eine Architektur die Theorie ist.
Das ist halt eher nicht der Fall.
Also die Aussage ist ja, das ist deutlich komplexer und es ist ja insbesondere so, dass der Peter Naur im Prinzip sagt, das ist nicht aufschreibbar.
Also die Aussage, die er trifft, ist, wenn ich 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 werde, ist halt so ein Kommentar am Ende, wo halt wer auch immer das Paper da halt irgendwie nochmal veröffentlicht hat, reingeschrieben hat, diese Metapher, die es bei so etwas wie XP gibt, bei Extreme Programming.
Ich würde behaupten, die gibt es auch bei Domain-Driven Design.
Das sei halt eine Theorie.
Also da gibt es diese Idee, dass man sagt, meine Software funktioniert so wie eine Fertigungsstraße.
Ich habe einen Auftrag und an den verschiedenen Stages von dem Auftrag werden Informationen für den Auftrag ergänzt.
So etwas zum Beispiel.
Das ist jetzt eben eine Metapher, die ist relativ kurz, die diskutiert das.
Es gibt ja auch diese Patterns of Enterprise, Quatsch, diese Poser Bücher, Patterns of Software Architecture, wo sowas drinsteht, nicht so ein Brightboard-Pattern, wo irgendwie alle Teile, was sie auf den gemeinsamen, im 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 eine scheinbare Lösung, hatte ich halt gesagt.
Ich würde also Dokumentation eher als Gedächtnisstütze sehen.
Wenn ich es aufschreibe, kann ich mich erinnern, was eigentlich gemeint ist.
Das ist halt hilfreich, aber die Theorie ist halt irgendwie was anderes.
Ich weiß nicht, wie es euch geht, aber für mich ist das halt so ein bisschen eine etwas magische Sache.
Also ich kann es nicht aufschreiben, es ist da, es ist halt Wissen.
Der Hinweis, dass 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, unzählige Meetings, ist es halt nicht erstaunlich, dass halt alles 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 LMS die Rolle eines Team-Mitglieds übernehmen und die Software erklären?
Gute Frage.
Ich wäre halt pessimistisch, weil die Dinge halt ein ganzes Kontext-Window haben.
Das heißt, sie können nicht die Software als Ganzes erfassen.
Das ist ja gerade die Aussage, dass das so eine nicht greifbare Theorie ist.
Also eigentlich reden wir darüber, dass wir ein Modell haben, was irgendwie weg abstrahlt vom konkreten Code, was die Konzepte dahinter definiert.
Eine LLM generiert Text, das denkt nicht, das baut insbesondere keine Theorien.
In dem Sinne kann also eine 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 einen Text, der hat scheinbar das System erklärt.
Und insofern kann das halt das tun.
Aber ich stelle damit am Ende in Abrede, dass Softwareentwicklung bedeutet, dass Menschen für Menschen Software entwickeln, bedeutet nämlich, dass ich eigentlich sage, also die Menschen, die das entwickeln, können zumindest teilweise durch LLMs ersetzen.
Und das ist halt relativ mutig.
Genau, hier steht, dass es das Gedankenexperiment Maries Zimmer gibt.
Ich muss sagen, ich kenne das nicht, was halt irgendwie ähnlich ist.
Genau, dann dieser Tod von Software, den er halt beschreibt.
Dort ist ja die Aussage, dass an der Stelle, wo sich 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.
Er sagt ja nur, dass man das nicht ernsthaft durch Dokumentation kann.
Und wenn es wirklich so ist, dass Software an ein Team gebunden ist und nur das Team es weiterentwickeln kann, das ist ein bisschen krass.
Ich glaube, dass dieses Handover natürlich eine Herausforderung ist.
Ich würde ein explizites Handover machen und ich würde versuchen, durch Pair-Programming solche Maßnahmen, diese Mitarbeit zu bekommen, über die er redet.
Aber ich glaube schon, dass man es im Prinzip einem anderen Team übergeben kann.
Und ich bin auch nicht sicher, dass er das gesagt hat, lasst doch das neue Team das Problem noch mal 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.
Das ist 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 dieser Tod des Systems.
Also das Paper sagt ja selber und gibt ja auch das Beispiel von diesem Compiler, wo am Ende eine Gruppe daran 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 hat gebaut, suboptimal ist.
Okay, das mag halt sein.
Aber wenn das eben die einzige Wahl ist, dass ich suboptimal Software entwickle, dann werde ich das wohl tun müssen.
Und deswegen finde ich 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 IT 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 seiner Gesamtzusammenhang ermöglichen.
Ja, stimmt.
Aber das, was der Naur ja sagt, ist, dass die Dokumentationsmöglichkeiten, die zum damaligen Zeitpunkt zur Verfügung gestanden haben, das eben nicht leisten.
Jetzt können wir uns Softwareentwicklungen im Jahr 2026 angucken.
Da gibt es ja sowas wie ARC 42, das C4-Modell, viele weitere Möglichkeiten, Architectural Decision Records oder so.
Ich würde behaupten, dass kein 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 Ziel sein?
Gehen wir nochmal von diesem prototypischen Fall aus, von dem ich das Gefühl habe, dass er bei mir im Consulting eine Rolle spielt.
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, dass wir zusammenarbeiten.
Pair Programming, Mob Programming, whatever.
Und dann wird sich das Wissen und diese Theorie eben diffundieren hin zu den neuen Mitgliedern des Teams.
Und das ist das, was der Naur ja auch sagt.
Das könnte man jetzt so machen, dass man sagt, wir machen ein Ensemble oder ein Mob oder wir machen ein Pair.
Und die Person, die jetzt neu ist im Team, setzt sie in die Tastatur und macht es.
Und die macht es nur, wenn sie es echt verstanden hat.
Das wird dazu führen, dass diese Person irgendwann das System hoffentlich verstanden hat.
Jetzt ist die Frage, ist das ein effektiverer Weg?
Ich würde behaupten ja.
Das wäre meine Erwartungshaltung.
Aber das muss man ausprobieren.
Dann wäre die andere Frage, ist das effizienter?
Also ist das weniger teuer?
Das Schreiben von echten Dokumentationen ist teuer und aufwendig.
Ich finde es nicht offensichtlich, dass das der billigere Weg ist.
Und dann ist eben die Frage, ob ich die Latte für Dokumentationen so hochlegen will.
Man muss halt hinzufügen, Dokumentation macht total viel Sinn.
Es hat Vorteile.
Ich frage halt immer bei Architektur Reviews nach der Dokumentation, weil es ist easy für den Auftraggeber, die Dokumentation mir einfach zu geben.
Das ist eine E-Mail.
Da wird irgendwas eingepackt und dann kriege ich es geschickt.
Aufwand zehn Minuten.
Fünf.
Ich kann es durchlesen und ich bin 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 nicht die richtigen Fragen zu stellen, um zu sagen, da sind übrigens Blindspots.
Das sind Themen, die nicht in der Dokumentation stehen.
Ich finde das jetzt auch nicht dramatisch.
Das zeigt den Wert meiner Ansicht nach von Dokumentation.
Nämlich, dass sie trivial reproduzierbar ist und man sie deswegen jemandem geben kann.
Aber es ist eben ein reduzierter Informationsumfang.
Dann schreibt Christian Beutenmüller, es gibt natürlich auch gute Theorien, die in der Software betreffen, aber nur Systeme, die sicherheitskritisch sind.
Echtzeitssysteme in Autos sind zum Beispiel formal spezifiziert.
Das ist aber nicht die Ebene, über die wir reden.
Also eine formale Spezifikation sorgt dafür, dass das System sicher die Anforderungen einhält.
Sobald ich das versuche, über formale Methoden, ähnlich wie mathematische Beweise, nachzuweisen.
Diese Theorie, über die wir sprechen, hat aber im Wesentlichen die Funktion, dafür zu sorgen, dass sich dieses System erweitern kann.
Das ist ja das, was SteNaur sagt.
Wenn ich ein System habe, was irgendwelche Ausgaben produziert, also 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 diese Theorie und das ist der Punkt, um den es geht.
Ich bin mir auch nicht sicher, ob dieser Theoriebegriff ein guter ist.
Eigentlich wirkt das auf mich eher wie die Gesamtmenge des Designs.
Christian Beutenmüller schreibt weiter, dass es erfordert sehr viel Disziplin und ist sehr teuer.
Eben wegen der Sicherheitsanforderungen, ja.
Aber nicht, dass es ein anderes Thema ist.
Ich nehme an, dass ich formal verifizierte Systeme bauen kann, die man nicht versteht.
Wenn ich ein formal verifiziertes System habe und ich habe eine Dokumentation und man sagt mir, erweitere das mal bitte, 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 aufgebaut ist, zerstört wird.
Dann schreibt Ruyogonikol, ich kann DDD doch auch in Funktionalitäten denken, also in Boxen.
Entspricht das dem Theoriebegriff?
Nein.
Das ist eine Architektur, das ist eine Aufteilung des Systems.
Jede Architekturdokumentation hat eine Aufteilung des Systems, nämlich Boxnamen.
Wir haben gerade diskutiert, und das wird sicherlich auch 85.
Fall gewesen sein, dass das völlig unzureichend ist.
Das wäre mein größtes Problem damit.
Ich finde das wolkig.
Das ist das, was im Prinzip der Peter Naur sagt.
Das ist nicht so richtig greifbar.
Das ist die Aussage.
Es gibt irgendetwas, was dieses Team weiß, was nicht so einfach aufschreibbar ist.
Dadurch können sie das System wirklich ändern.
Ich finde Theorie als Begriff auch schwierig.
Ich würde mir hoffen, dass man es anders nennt.
Es ist ein tiefes Verständnis des Systems.
Ich finde den Impact zur realen Welt nicht so offensichtlich.
Im Chat gibt es sonst nichts, was ich noch diskutieren wollen würde.
Es gab eben die, und im Formular bei Software-Technik-Stream auch nicht.
Dann würde ich erst mal sagen, vielen Dank für die Aufmerksamkeit.
Vielen Dank für die vielen Diskussionen.
Das hat mich sehr gefreut.
Ehrlich gesagt, ich kenne jetzt nicht so ein Mainstream-Thema, würde ich jetzt mal unterstellen.
Da freut es mich dann immer besonders, wenn es so rege Beteiligung gibt.
Ausblick.
Wir werden nächste Woche sehr sicher keine Episode haben.
In der Woche darauf wird es dann zwei Episoden live geben von HMS Architecture.
Da könnt ihr gespannt sein, wird es dann auf der Webseite stehen.
Christian Beutemüller schreibt, dann die drastische Frage, ob es einen wirklichen Unterschied zwischen der Theorie und dem gesamten Code gibt.
Ja, ich kann jemandem den Code auf den Tisch legen.
Das haben sie ja gemacht.
Also bei dem Compiler.
Die haben die Theorie nicht.
Wenn sie versuchen, den Code zu ändern, machen sie Änderungen, die der Theorie widersprechen und die Qualität des Systems reduzieren.
Da ist das Problem.
Das ist was anderes.
Der Code ist nur etwas, was sich daraus ergibt, wie diese Theorie aussieht.
MKlinke82 auf YouTube fragt, wäre der Begriff mentales Modell vielleicht geeignet als Theorie?
Ja, vielleicht.
Vielleicht ist er auch gar nicht schlecht.
Das wäre auch eine Alternative.
Ich finde das bei den Begrifflichkeiten immer schwierig.
Eigentlich ist es bei solchen Papern so, dass der Peter Naur in diesem Fall einen Begriff einführt für etwas, was er beschreibt und definiert.
Da ist der Name eigentlich egal.
Er hätte es auch Gummibärchen nennen können.
Nur die Theorie ist näher dran.
Das mentale Modell ist auch näher dran.
Die Kritik, die ich 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.
Es ist eher so etwas Architektonisches, Designmäßiges, aber nicht größer.
Man könnte auch sagen, wenn man wirklich das gesamte Design einer Software verstehen will, die Designkonzepte, das lässt sich nicht aufschreiben.
Diese Designkonzepte, dass es das wohl meiner Ansicht nach eher redet oder wie ich das sehen würde.
Gut, dann würde ich sagen, vielen Dank.
Schönes Wochenende und vielen Dank, wie gesagt, auch für die Diskussion.
Ich hoffe, dass man sich dann irgendwo wieder sieht.
Entweder in der realen Welt, gerne auch im Stream oder sonst auf einem anderen Weg.
Bis dahin, vielen Dank und schönes Wochenende.