Folge 304 - Programmierung als Theoriebildung | Zusammenfassung

Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Software-Entwicklung ist weit mehr als nur das Schreiben von Code. Diese Einsicht verdanken wir Peter Naur, einem Pionier der Informatik, der bereits 1985 ein Paper mit dem Titel “Programming is Theorybuilding” veröffentlichte. In einer Zeit, in der Künstliche Intelligenz verstärkt in der Softwareentwicklung Einzug hält, gewinnt Naurs zentrale These neue Relevanz: Programmierung ist das Aufbauen einer Theorie über die Realität.

Die Kernthese: Mehr als Code-Produktion

Naur argumentiert, dass Programmierer nicht einfach nur Code produzieren. Stattdessen entwickeln sie eine umfassende Theorie darüber, wie bestimmte Elemente der realen Welt durch ein Programm abgebildet und unterstützt werden sollen. Diese Theorie ist das Fundament – wichtiger noch als der Code selbst, die Dokumentation oder die Spezifikation.

Um diese These zu illustrieren, beschreibt Naur zwei prägnante Fallstudien: Bei der Entwicklung eines Compilers zeigt sich, dass nur das ursprüngliche Entwicklungsteam versteht, welche Design-Entscheidungen sinnvoll sind. Wenn andere Teams Änderungen vornehmen, ohne diese Theorie zu verstehen, zerstören sie die elegante Struktur des Systems. Ähnlich verhält es sich bei Echtzeitsystemen für industrielle Anwendungen: Die Wartungsprogrammierer, die das System über Jahre hinweg gepflegt haben, können schnell erkennen, welche Modifikationen für den Einsatz bei einem Kunden die Systemintegrität gefährden würden.

Warum diese Theorie nicht dokumentierbar ist

Ein zentraler Punkt Naurs lautet: Diese Theorie lässt sich nicht vollständig aufschreiben. Obwohl in seinen Fallstudien ausführliche Dokumentation vorhanden war, half diese den neu hinzukommenden Teams nicht weiter. Warum? Weil echtes Verständnis durch direkte Zusammenarbeit entsteht – ähnlich wie beim Erlernen eines Musikinstruments. Man kann Musiktheorie aus Büchern lernen, doch das Instrument selbst erfordert praktische Anleitung durch einen erfahrenen Musiker.

Diese Erkenntnis hat weitreichende Konsequenzen für die Teamstabilität und Knowledge-Transfer in Softwareprojekten.

Implikationen für KI und automatisierte Code-Generierung

Besonders interessant wird Naurs These im Kontext von Large Language Models (LLMs). Diese können zwar Code generieren, der funktioniert, doch sie bauen keine Theorie auf. Sie haben keinen tiefgehenden Bezug zur Realität, die das System abbilden soll. Das bedeutet: Code, der von LLMs ohne menschliches konzeptionelles Verständnis generiert wird, kann zwar äußerlich korrekt sein, wird aber langfristig zu schwer wartbaren Legacy-Systemen führen.

Praktische Konsequenzen

Aus Naurs Theorie ergeben sich konkrete Empfehlungen:

• Teamkontinuität ist wertvoll: Stabile Teams, die gemeinsam an Systemen arbeiten, entwickeln das notwendige theoretische Verständnis.
• Onboarding durch Zusammenarbeit: Neue Entwickler sollten durch Pair-Programming und gemeinsame Arbeit in die Theorie eingeführt werden, nicht durch Dokumentation allein.
• Dokumentation als Gedächtnisstütze: Dokumentation hat ihren Platz, ersetzt aber nicht das direkte Lernen im Team.
• Vorsicht mit automatisierter Generierung: Wo Wartbarkeit und Erweiterbarkeit zentral sind, sollte menschliches theoretisches Verständnis nicht durch reine Code-Generierung ersetzt werden.

Fazit

Peter Naurs Paper aus 1985 bietet einen kraftvollen konzeptionellen Rahmen für das Verständnis von Softwareentwicklung. Programmierung ist nicht die mechanische Umsetzung von Anforderungen – sie ist ein tiefes intellektuelles Unterfangen, bei dem Menschen ein kohärentes Modell der Welt entwickeln. In einer Zeit, in der Künstliche Intelligenz von sich behauptet, Software zu schreiben, erinnert uns Naur daran, dass das Wesentliche an Softwareentwicklung nicht in der Textgenerierung liegt, sondern im menschlichen Verständnis komplexer Systeme. Nur wer diese Theorie besitzt, kann Software nachhaltig entwickeln, warten und evolieren.