1.5.2009

Theorie und Abstraktion (2)

(Themenanfang)

Es gibt eine lange Liste von Abstraktionen, ohne die sich niemand mehr im Bereich von Computersoftware bewegen könnte. Das fängt an mit der Beschreibung von Maschinenbefehlen in Assembler - hier ist jeder Zahl, die einen Befehl oder einen Speicherplatz in der CPU („Register“) ausdrückt, ein Wortkürzel zugeordnet. Dadurch muß man nicht mehr jene binären Zahlen entziffern bzw. eintippen, mit denen die CPU gespeist wird, sondern kann sie benennen. Es geht dann weiter mit sog. Hochsprachen, in denen man sich von der direkten Logik der Maschinenebene lösen kann, und logische Konstrukte verwendet (»if/else«, »while«, etc.), die ein Compiler erst in Maschinensprache übersetzt. Es geht weiter mit objektorientierten Sprachen, die auf einer höheren Ebene Abstraktionen erlauben, indem in ihnen nicht mehr Speicherplatz und Programmablauf die zentrale Rolle spielen, sondern »Objects«, die sowohl Daten als auch Methoden bereitstellen, und in denen ein bestimmtes Verhalten realisiert ist. Auf einer anderen Ebene gibt es in der Informatik Forschung über bestimmte Design-“Patterns“ - das sind einmal allgemein gültige Algorithmen („sortieren”, „suchen”, etc.), zum anderen ganze Problemfelder, die in unterschiedlichen Zusammenhängen immer wieder neu auftauchen und abstrakt gelöst werden können („Proxie”, „Iterator”, etc.pp).

Wenn man eine Applikation entwirft, versucht man – noch bevor nur eine Zeile Code geschrieben ist – das Projekt abstrakt zu planen. Man sieht sich an, was man schon in den Händen hält und was sich davon wiederverwenden läßt, und entwirft Lösungen, die zunächst nur auf dem Papier stehen. Das ist nicht sehr viel anders als die Arbeit des Architekten beim Bau eines Gebäudes (tatsächlich gibt es die Bezeichnung des „Software-Architekten”, und – zumindest unter meinen Kollegen – ist oft die Rede von der „Baustelle“, wenn man an einem bestimmten Codebereich arbeitet).

Man sollte meinen, daß man jetzt nur noch den Code schreiben muß, und danach ist alles fertig. Tatsächlich gibt es eine ganze Reihe von Versuchen, die Planung am Anfang soweit voranzutreiben, daß man einen kompletten Entwurf des Programms auf dem Papier hat, bevor die Programmierer mit ihrer Arbeit beginnen (was man z.B. als Grundlage für Vertragsverhandlungen oder Zeitmanagement verwenden könnte). In der Praxis stellt sich heraus, daß die „Wasserfall-Verfahren“ regelmäßig scheitern.[1]

Die bei der Planung einer Applikation vorgenommenen Abstraktionen müssen idR im Projektverlauf revidiert und angepaßt werden. Im Vorfeld ist schlicht nicht absehbar, auf welche Probleme man erst beim Schreiben und Testen des konkreten Codes stoßen wird. Es gibt regelmäßig Fälle, bei denen sich herausstellt, daß selbst Grundannahmen, von denen man beim Design ausgegangen war, unvollständig oder unpraktikabel sind. Man muß dann aus der laufenden Codeproduktion aussteigen und das Design anpassen – mit der Folge, daß gelegentlich auch bereits geschriebener Code hinfällig wird und neu geschrieben oder doch zumindest angepaßt werden muß. Solches „Refactoring“ findet über die gesamte Lebensdauer eines Programms (im Fall von Cubase bislang stolze 20 Jahre) statt – wobei man, wenn man das nicht konsequent betreibt, immer wieder Codebereiche „verliert“. Man hat damit zu kämpfen, daß sich Code in „Legacy“-Code verwandelt, den keiner mehr verstehen oder warten kann, und der sich immer schlechter in den Rest des Programms integrieren läßt.

Man hat es mit Abstraktionen zu tun, die man ständig anpassen muß, weil sich der ihnen zugrunde liegende Gegenstand permanent verändert.

Wenn man oben stehenden Satz außerhalb des Kontexts dieses Textes liest, wird man zunächst nicht an Computer, sondern an Gesellschaftstheorie denken. Ich bin nicht wirklich sicher, ob man die Analogie zwischen Theoriebildung und Softwaredesign tatsächlich ziehen kann, oder ob es sich um zwei Bereiche handelt, die nichts miteinander zu tun haben. Es kann sein, daß sich irgendwo ein gewaltiger Denkfehler versteckt, der, wenn ich ihn irgendwann finde, dazu führt, daß ich die Hände über dem Kopf zusammen schlage. Trotzdem – der Versuch, die beiden Begriffe zueinander in Beziehung zu bringen, könnte sich lohnen, weil Software für Beobachtung gut zugänglich ist. Sie ist längst nicht so komplex wie eine ausdifferenzierte Gesellschaft, gleichzeitig aber auch nicht so trivial, daß sich jeder Vergleich von vornherein verbietet. Das Entstehen von Abstraktionen könnte man hier also gleichsam modellhaft vorführen – wobei die Frage offen bleibt, ob und wie weit sich Folgerungen für (oder gar Forderungen an) das Entstehen von Gesellschaftstheorie ergeben.

  1. [1] Ich habe mit der Beschreibung eines alternativen Konzepts - den agilen Entwicklungsmethoden - zumindest begonnen.

(Kommentarfunktion z.Zt. deaktiviert.)