Bottom Up und Top Down

Die Ansätze beim Schreiben von Software lassen sich kurz in zwei Ansätze zusammenfassen: Bottom up oder Top Down. Diese Ansätze entspringen der Organisation, in der eine Software entstanden ist.
Innerhalb von Firmen herrscht eine Top-Down Kultur: Sie ist geprägt von Hierarchien und Organisation. Im Extremfall ist sie fast militärisch. Organisation ist nur möglich über Professionalisierung, das heißt in der Ausbildung unterschiedlicher Organisationsrollen, und Arbeitsteilung. Der operativ wirkende Mitarbeiter steht dabei am unteren Ende der Hierarchieskala. Große Projekte werden über Planung in oberen Hierarchieebenen bewerkstelligt. usw. Der Transfer der ursprünglich militärischen Organisationsform auf die Privatwirtschaft und die Einführung des Begriffs Management ist eine der Leistungen der vergangenen 200 Jahre, die den Wohlstand der Menschheit wohl am meisten vermehrt haben. Erst dadurch wurde die Koordination komplexer Prozesse, die Interaktion mit den komplexen Systemen ganzer Gesellschaften möglich.
Das Gegenbeispiel ist die selbstverwaltete Organisation einer (staatlichen) Universität. Hier ist die Verwaltung lediglich ein Anhängsel, eine Art Dienstleister der einzelnen Wissenschaftler. Im Wissenschaftsbereich selbst gibt es kaum Professionalisierung, kaum Arbeitsteilung. Die Anreizsysteme sind für alle Mitarbeiter dieselben: Nur über Publikationen kann der Einzelne Aufstieg erreichen, nicht aber, indem er z.B. als Projektmanager, Recruiter oder Marketing-Fachmann arbeitet. Gegeben ein beschränktes Budget von Stellen, wird sich ein Institut nie dazu entschließen, etwas anderes als einen Wissenschaftler einzustellen - es sei denn, man überschreitet eine gewisse Größe und steht z.B. unter starkem öffentlichen Rechtfertigungsdruck.
Das führt dazu, dass Projekte an Universitäten im Normalfall kaum über ein paar Personen hinaus skalieren. In vielen Fällen herrscht sogar das Bild des einsamen Forschers vor, der abgeschottet von der Außenwelt über Büchern brütet. Vor die Herausforderung gestellt, dennoch eine komplexere Aufgabe bewältigen zu müssen, sind viele Projekte zum Scheitern verurteilt: Da keine Organisation dafür sorgt, talentierte Ressourcen in unterschiedliche Rollen zu alloziieren, ist es eine Sache des Glücks, ob die Talente im Projekt gerade so verteilt sind, dass die Herausforderung gemeistert werden kann. In allen Fällen führen jedoch fehlende Anreizsysteme dazu, dass sich die Situation nicht selbst optimiert: Ein Organisator wird in seiner Organisatorrolle nicht die Bestätigung erleben (etwa durch eine Beförderung) wie dies in der Privatwirtschaft gegeben ist.
Es gibt natürlich Ausnahmen, die durch äußeren Druck entstehen. Zum Beispiel ist es für einen viele Physiker heute kaum mehr möglich, ohne millionen- oder milliardenschwere Technologie Forschung zu betreiben. Hier muss es Spezialisten geben, spezielle Stellen, die dann jedoch nicht in der Forschung, sondern eben auf operativer Ebene angesiedelt sind. Ebenso muss ein Krankenhaus organisiert werden.
Doch zurück zur Software: Wie gesagt, spiegelt sich die Organisationsform in der Organisation der Software wider: Es gibt top-down und bottom-up Software. Es gibt auch unterschiedliche Märkte dafür: Eine bottom-up Software wird von einem Privatunternehmen in vielen Fällen weniger stark nachgefragt werden wie eine top-down Software.
Ein paar Beispiele dazu: Unix ist eine klassische Bottom-Up-Software, ein Abkömmling öffentlicher und privater Forschungs-Organisationen. Unix-Erfinder haben dies ja auch zur Philosophie gemacht und einige Prinzipien aufgestellt. Die Essenz ist: Enge die Funktionsweise Deines Programms ein, schau, dass es das Problem, das es angeht, auch wirklich gut löst, und versiehe es mit standardisierten, einfachen Schnittstellen, die ein Mensch noch versteht. Das heißt, Unix Pipes, Textuelle Formatierung von Input und Output, etc. Schau, dass das System kompositional wird, indem ein Programm den Output des anderen als Input nimmt (f | g entspricht also der Komposition von Funktionen, g(f(x)) - eine Arbeitsthese wäre, dass in Universitätsumgebungen eher ein funktionaler Ansatz zu finden ist, was sich auch in einer größeren Verbreitung von funktionalen Programmiersprachen widerspiegelt. Doch dies hat sicher auch andere Gründe).
Das Unix-System passt perfekt in die Bottom-Up-Welt: Einzelpersonen können einzelne Programme schreiben, die durch Komposition zum größeren Ganzen werden.
Die Kehrseite ist jedoch, dass es keinen "top-down" Blick auf das Gesamtsystem mehr gibt. Das System lokaler Kontrakte funktioniert auf Kommandozeilenebene recht gut. Schon hier gibt es allerdings gewisse Reibungsverluste, die sich in unterschiedlicher Syntax verschiedener Tools zeigen. Ein Beispiel: Manche Unix-Befehle zeigen über "-?", andere über "-h" oder über "--help" eine Hilfe-Seite an. Es gibt keinen durchgängigen Standard für Tastaturbelegungen, etc. Der Bereich Usability-Forschung wurde daher auch nicht an Universitäten erfunden - er erfordert einen Blick über Modulgrenzen hinweg - eine Anforderung, die Universitäts-Software nicht leisten kann.
Als Gegenbeispiel seien hier die Betriebssysteme von Apple und Microsoft genannt (man möge mir verzeihen, sie in einem Atemzug zu nennen). Sie (insbesondere letzteres) sind von ihrer Machart her top-down organisiert: Unter Windows gibt es ja z.B. eine zentrale Registrierungsdatenbank für Konfigurationen, zentrale Dienste wie ein System für verteilte Komponenten, ein durchgängiges Tastatur-Layout, ein systemweites Hilfesystem etc. Man mag sich bei manchen dieser Erfindungen streiten, ob sie sinnvoll waren, viele Dinge wurden jedoch später auch auf Unix-Systeme übernommen: So hat z.B. das KDE-Projekt viele dieser Errungenschaften auf Unix-Systeme übertragen: Ein Komponentensystem eingeführt, das sehr nahe an dem von Windows angelehnt ist, eine standardisierte Benutzeroberfläche mit zentraler Systemsteuerung eingeführt, Shortcuts standardisiert, etc. Es bleibt festzustellen, dass hier nur sehr wenig wirkliche Innovation stattfindet. Die meisten Programme unter KDE oder Gnome sind Kopien ihrer kommerziellen Pendants.
Ähnliches kann man aber auch im Bereich der Programmierung entdecken: So wurde die erste objektorientierte Programmiersprache, Simula, zwar an der Universität Oslo entwickelt. Später kam Smalltalk vom Xerox PARC hinzu, immerhin schon einer privaten Forschungsorganisation. Durchgesetzt hat sich das objektorientierte Paradigma jedoch durch zwei Entwicklungen: Einmal die Verbreitung von C++ (entwickelt bei AT&T) und die Verbreitung von Benutzeroberflächen, für die sich Objektorientierung besonders eignet. Ich möchte argumentieren, dass das objektorientierte Paradigma wie geschaffen für top-down Organisationen ist. Während der Unix-Ansatz dafür gemacht ist, Daten zu manipulieren, ist der objektoerientierte dazu da, die Welt abzubilden und Strukturen zu schaffen.
Man könnte auch sagen: Der funktionale Ansatz stellt Verben in den Mittelpunkt, der objektorientierte die Substantive. Hier geht es um die Modellierung von Beziehungen und Hierarchien und letztlich um das Erzeugen einer ganzheitlichen Sicht auf ein System.
In ihrer Ausprägung als statisch getypte Sprachen haben C++, Java und Co. überdies einen Vorteil: Sie können Garantien geben. Eine arbeitsteilige Organisation muss diese Möglichkeit haben, indem in Spezifikationen festgeschrieben werden kann, wie die Schnittstellen eines Programms aussehen. Eine fluide Definition, dass man eben Text bekommt, der wieder geparst werden muss, oder einen nicht genau spezifizierten Datentyp, erzeugt bei einem Projektmanager nur Unbehagen. Bei der Zusammenarbeit verschiedener Organisationen wird dies dann zum Problem. Ein Kunde wird die Eigenschaften einer Schnittstelle festschreiben lassen, da eine Verletzung unter Umständen sein Geschäftsmodell gefährden kann. Würden keine ausreichenden Garantien gemacht werden können, könnte er den Vertragspartner nicht zur Rechenschaft ziehen. Die Frage, ob im Bereich IT dynamische Sprachen wie Python eine Chance haben, lässt sich daher einfach beantworten: Nein.
Doch nicht nur die Programmiersprachen verraten ihre Herkunft: Auch die Welt der Application Server, der Komponenten-Architekturen, sogar Programme wie Eclipse verraten ihre Herkunft als Produkte von der Industrie, für die Industrie.
Zum Glück sind die Grenzen heute nicht mehr so streng, wie sie früher einmal waren. Entwicklungen in Industrie und Forschung schwappen in relativ kurzer Zeit zur anderen Seite über. Ein Beispiel ist die größere Verbreitung von Unix-Tools unter Windows, Windows-ähnliche Programme unter Linux, oder der Unix-Unterbau von Mac OS X. Derzeit verbreiten sich auch wieder mehr dynamische Programmiersprachen in der Industrie (allerdings wohl eher unter der Motorhaube und nicht an den Schnittstellen).
Viele Software-Firmen sind in ihrer Art auch ähnlich zu Universitäts-Organisationen: Entweder, indem sie kleine, innovative Ausgründungen sind, oder, indem sie eine Research-Abteilung enthalten. In beiden Fällen wird man eher dem Unix-Paradigma zugeneigt sein. Es ist interessant zu beobachten, wie sich eine kleine High-Tech-Firma wandelt, wenn sie wächst: Wie ein reiner Unix-Shop mit einem Produkt, das den Prinzipien der kleinen Tools und der dynamischen Programmiersprachen verhaftet ist, immer mehr zu einem Industriedienstleister wird, mit einer größeren Bedeutung von Application Servern, garantierten Interfaces und einer größeren Bedeutung von Windows. An irgendeinem Punkt wird man sicher den Research-Bereich davon wieder abkoppeln (oder hat dies in einzelnen Teams schon getan), um Bottom-Up-Innovationen zu ermöglichen.
Für den Einzelnen, der sich zwischen diesen Welten bewegt, stellt sich nun die Frage, welche Technologie zu welchem Zeitpunkt verwendet werden soll. Wer die Möglichkeit (das heißt: Wahlfreiheit und Überblick) hat, sollte sich nun also wertfrei derjenigen Techniken bedienen, die der Lösung eines Problems und der Organisationsform, in der man sich befindet, am besten entsprechen. An einer Universität sollte man daher nicht versuchen, große Frameworks der Industrie ohne kritische Prüfung zu übernehmen: Ob das Applikationsserver oder Benutzerschnittstellen sind: Unter Umständen erfordern sie wochenlange Schulungen und Spezialisierung. Auf der anderen Seite liefern sie vielleicht eine bessere Benutzbarkeit als typische Unix-Tools. An der Universität sollte man Programme wohl eher in der Form Input-Verarbeitung-Output schreiben. Kommandozeilentools, zusammensetzbar, von einer Person beherrschbar. Die universitäre Sichtweise würde eher erwarten, dass diese einzelnen Programme hervorragend funktionieren, egal wie groß der Input und der Output ist. Das Programm würde sich durchsetzen, wenn der Einzelne gut funktioniert, eine gewisse Genialität an den Tag legt. Das Problem würde einmal gelöst, und das Programm in die Ewigkeit der Unix-Gemeinde eingehen.
In der Industrie würde man eher eine Objektorientierte Sichtweise annehmen, zusammen mit gewissen Techniken, die in der funktionalen Programmierung automatisch gegeben wären, wie "Dependency Injection". Man würde sich organisieren, ein Team bilden, einen Projektplan erstellen, die Abhängigkeiten durch Definition von Komponenten reduzieren, iterative Entwicklungszyklen einführen, usf. Das Programm setzt sich dann durch, wenn das Team gut funktioniert. Je organisierter das Team, desto weniger genial muss der Einzelne sein. Im Extremfall sind es militärische Organisationen wie Accenture, die die Durchschnittlichkeit der Einzelnen komplett ausbügeln können, die im statistischen Mittelwert aber dennoch "brute-force", mit viel Arbeitskraft, viel komplexere top-down-Projekte stemmen können als das an der Universität je möglich wäre.