Von der Notwendigkeit, sich in abstrakten Welten bewegen zu können

Vom Programmierer zum Software-Architekten: Software-Entwicklung ist einfacher und zugleich niveauvoller geworden

Vor über 30 Jahren war das Programmieren von Computern einigen wenigen auserlesenen Spezialisten vorbehalten. Heute, nachdem sich die Computer zu einem Alltagsgegenstand entwickelt und moderne Entwicklungswerkzeuge eine große Reife erreicht haben, kann jeder Software schreiben, der sich dazu berufen fühlt. Wird der Beruf des Programmierers also aussterben, nachdem kein Expertentum mehr nötig ist und jeder sich seine von ihm benötigte Software selbst schreiben kann?

Vorab gesagt: Es besteht keine Gefahr. Softwareentwicklung ist heute ein fester Bestandteil der Berufswelt und deckt viele technische Bereiche ab. Immer mehr Geräte werden programmiert und neue Anwendungen für Software entdeckt. Die Spannweite reicht vom einfachen Haushaltsgerät bis hin zum autonomen Roboter, vom Auto bis zu Steuerungen großindustrieller Anlagen. Finanzwelt, Mikrobiologie und Handy sind ohne Software undenkbar. Daraus erwachsen differenzierte Anforderungen an die Technik und Methodik der Softwareentwicklung, die Entwicklungswerkzeuge noch lange nicht vollständig automatisieren können. Der Mensch wird folglich auch weiterhin noch eine wichtige Rolle spielen.

Wegen der breiten Anwendung von Computern muss ein Programmierer in einem Berufsfeld agieren, dessen Wissenszuwachs enorm ist (jede oder jeder, der nach einer Berufspause wieder einsteigen will weiß, was gemeint ist). Und diese Ausweitung ist nicht nur graduell: Quantencomputer, DNA-Computer und dergleichen mehr sind völlig neue Funktionsprinzipien, die selbst für viele Insider der Softwarebranche ein Buch mit sieben Siegeln sind. Wie am Fließband werden ständig neue komplexe mathematische Algorithmen entwickelt, die es in einem Programm umzusetzen gilt. Heutige Bildverarbeitung für Sicherheitstechnik und die stetige Zunahme statistischer Verfahren belegen dies.

Wenn also die Entwicklungswerkzeuge trotz ihres Fortschritts auf absehbare Zeit noch keine vollautomatische Softwarefabrik hergeben und die Aufgabe für Programmierer offensichtlich nicht einfacher wird, wie muss man sich dann in Zukunft die Rolle des Softwareentwicklers vorstellen? Was wird man von ihm wohl erwarten?

Technische Ausgangssituation

Moderne Entwicklungssysteme werden mit dem Anspruch entwickelt, Software immer "leichter" zu produzieren. Was heißt nun "leichter"? Es geht schlicht um Produktivität: Wie viel Arbeit muss ich investieren, damit die gewünschte Software Realität wird. Als Maß könnte man hier die Komplexität des fertigen Programms (meist als Zahl der Programmzeilen ausgedrückt) oder die Zahl der benötigten Arbeitsstunden nehmen.

Eine weitere Dimension des "leichter" betrifft das notwendige Fachwissen. In den Anfängen der Computer war spezielles Know-how notwendig. So musste man früher wissen, welche Elemente der Computerhardware zu programmieren waren, um z.B. einen Punkt oder einen Buchstaben auf dem Bildschirm erscheinen zu lassen. Das Vokabular der Fachleute war gespickt mit Worten wie "Register", "Adresse" und "Taktzyklus". Dazu war dieses Wissen auch spezifisch für einen bestimmten Computer oder gewisse Produktfamilien. Mit dem technischen Fortschritt wanderte dieses Wissen vermehrt von der Software in die Programmierwerkzeuge und in die Betriebssysteme (wie Microsoft Windows, Linux usw.). So genügt heute der Aufruf einer abstrakten Funktion, dem jeder direkten Bezug zur Hardware fehlt und die viele Betriebssysteme anbieten: Statt in die Speicherzelle mit Adresse "0xFFFF0" eine Zahl zwischen 0 und 255 einzuschreiben, ruft man einfach die Funktion "print" auf.

Nun wurde eingangs erwähnt, dass dem Programmierer aber mehr und mehr Kenntnisse abverlangt werden, weil sich die Wissensgrenzen seines Faches immer weiter ausdehnen. Auch diesbezüglich helfen moderne Werkzeuge. Mitgelieferte Programm-Module (sog. Bibliotheken) decken verschiedene technische Anwendungsfälle ab: Es gibt Bibliotheken z.B. für Grafik, Datenbanken, Kommunikation. Sie erschließen ihrem Anwender technische Bereiche, ohne dass dieser Fachmann auf dem jeweiligen Gebiet sein muss. Aber damit nicht genug. Seit einigen Jahren sind "Wizzards" üblich. Das sind Werkzeuge, die einem Tutor gleich Schritt für Schritt ganze Anwendungen erstellen helfen. Datenbankanwendungen, mit .Net der Firma Microsoft programmiert, sind dafür ein schönes Beispiel. Man muss kaum etwas über relationale Datenbanken, Normalformen oder den ganzen anderen technischen Grundlagen wissen, um eine Anwendung zu erstellen, die z.B. Adressen verwaltet. Der Wizzard fragt einige wichtige Parameter ab - und schon hat man ein Programm, das man höchstens noch etwas anpassen muss. Sogar ganze Webserver sind auf "Knopfdruck" zu haben. Das wohl bekannteste Beispiel für ein modernes Entwicklungswerkzeug dieser Art ist Visual Basic der Firma Microsoft. Die Zahl der Visual Basic-Anwender ist entsprechend Legion.

Auf der Seite der Programmiersprachen ist eine entsprechende Entwicklung zu beobachten. Wurde früher mit einem Befehl ein Byte (also letztlich eine Zahl) von einem Ort zum anderen transportiert oder z.B. addiert, so bewirken Befehle moderner Programmiersprachen komplexe Abläufe. In der Sprache APL etwa lassen sich Listen und Matrizen mit einem einzigen Befehl manipulieren. Mit anderen Worten: Auch die Sprache, mit der eine Lösung codiert wird, wird abstrakter (weil sie sich von konkreten Bits und Bytes löst) und mächtiger. Sie befreit den Softwareentwickler von der Sorge über unnötige Details. Darüber hinaus wird das damit geschriebene Programm auch leichter lesbar, weil Befehle wie "print" nahezu intuitiv verständlich sind, im Gegensatz zu "ld a,e". Solche Überlegungen haben letztlich auch die Entwicklung von Sprachen wie COBOL und BASIC beeinflusst.

Blickt man in die Zukunft, so scheint es, dass sich die hier skizzierte Entwicklung der Werkzeuge, Programmiersprachen und Betriebssysteme fortführen wird und entsprechend auch die durch sie erreichte Produktivität weiter steigt. Erste Berichte über die Zukunft der Sprache C#, des Entwicklungssystems Visual Studio und des aktuellen Betriebssystems Windows Vista (alle von Microsoft) deuten an, dass die Werkzeuge der nächsten Generation noch mehr vermögen, also die Abstraktion noch weiter anheben und den Softwareentwickler von der Beschäftigung mit technischen Niederungen noch mehr befreien.

Den Höhepunkt dieses Fortschritts bezeichnet das Stichwort "Software Factory". Darunter werden Werkzeuge verstanden, die ausgehend von einer mehr oder weniger kompakten und abstrakten Beschreibung Teile einer Software automatisch erzeugen. Aber, und das ist der Knackpunkt, eben nur Teile. Und diese Teile sind dann nicht immer optimal, denn eine Maschine, deren Elemente von Hand gefertigt werden kann, lässt sich optimal auf ihre Aufgabe hin konstruieren und bauen. Je mehr standardisierte Teile zu verwenden sind, desto mehr wird die resultierende Maschine zu einem Kompromiss. Aber dennoch ist das Bestreben, Software auf Knopfdruck erzeugen zu lassen, ungebrochen.

Bis hierher verfällt man also leicht dem Schluss, mit diesen Werkzeugen und Programmiersprachen könne jeder programmieren, da kein Expertentum mehr notwendig sei. Und tatsächlich ist es einfach, irgendein lauffähiges Programm mit modernen Hilfsmitteln zu erstellen. Dieser vermeintliche Ist-Zustand, den übrigens manche Experten als einen Schwachpunkt heutiger kommerzieller Softwareentwicklung anführen, entpuppt sich bei näherer Betrachtung aber als Trugbild. Um das zu begründen sei nochmals betont, dass hier die industrielle bzw. kommerzielle Softwareentwicklung Gegenstand dieses Artikels sein soll, bei der Software ein Produkt ist, für das Geld bezahlt wird und für dessen Funktionssicherheit gehaftet werden muss. Denn für bestimmte Anwendungen oder im Privatbereich ist es sicher sinnvoll, dass wirklich "jeder" Interessierte sich ohne viel Aufwand seine benötigte Applikation erstellen kann.

Warum ist also doch bei allem Fortschritt Expertentum notwendig? Zum einen muss auch weiterhin irgendjemand die Computerhardware ansprechen, und die Bibliotheken mit ihrem enthaltenen Fachwissen schreiben sich nicht von alleine, ebenso wenig wie die Entwicklungswerkzeuge. Die Software, die direkt mit der Hardware kommuniziert, sind heute die Betriebssysteme. Ihre Autoren sind entsprechend jene Spezialisten, die jeden Winkel der Computerhardware kennen. Oft sind dies Fachleute der Firma, die auch diese Hardware gebaut hat. Was die Bibliotheken und Werkzeuge betrifft, so gehen sie natürlich ebenso auf Spezialisten zurück.

Man kann also festhalten, dass zumindest diese Art von hochqualifizierten Fachleuten nicht so schnell aussterben wird. Dies ist allerdings eine im Vergleich zur Gesamtmenge der Softwareentwickler kleine Gruppe. Ein anderer Aspekt ist viel gewichtiger: Software ist die Notation einer Lösung, eines Algorithmus, den es zuallerst zu entwickeln gilt. Hier hilft keine Factory mehr, das ist die Urdomäne des menschlichen Wissens und Denkens.

Wandel von Wissen und Denken

Bisher wurde nur von Wissen als Voraussetzung dafür gesprochen, etwas mit gegebenen Werkzeugen zu produzieren, also, wenn man so will, vom handwerklichen Aspekt der Softwareentwicklung. Aber Problemlösung wird erst ermöglicht durch ein Modell der Welt und deren Begriffe (im philosophischen Sinn), die diese Welt beschreiben, das Wissen strukturieren und neues Wissen einordnen helfen. Ist der Algorithmus nun dort gedacht, so muss er aber übersetzt werden in das Denkmodell und die Begriffe der verfügbaren Programmiersprache. Register, Bits und Bytes waren die Begriffe, in denen die Entwickler bis in die 80-iger Jahren gedacht haben und auch denken mussten, wenn eine Lösung programmiert wurde. Weder Assembler noch C als Programmiersprachen waren damals in der Lage, dem Entwickler ein Modell zu präsentieren, das wesentlich über den Bestandteilen der zu programmierenden Computer, eben der Register, Adressen und Bytes, lag. Die Übersetzungsarbeit war gewaltig.

Allerdings bildete die Sprache "C" die Brücke zu den Denkweisen, die im Folgenden immer wichtiger wurden, um diese Übersetzungsarbeit zu vereinfachen. Gemeint ist die Sichtweise der Algorithmen. Begriffe aus der Lehre der Datenstrukturen wie "Baum", "Liste" oder "String" drängten die Existenzberechtigung von den Begriffen "Register" usw. auf Bereiche zurück, für die sie unumgänglich waren. Diese Entwicklung führte zu Programmiersprachen, deren Begriffswelten schon sehr nahe dem Denkmodell der eigentlichen Problemlösungen stehen.

Inzwischen kann der Programmierer in Tabellen, Objekten oder Listen denken. Es sind Sprachen verfügbar, deren Elemente als direkte Manifestation theoretischer oder mathematischer Konzepte gelten können. Da diese Konzepte auf bestimmte Problemklassen hin optimiert wurden, lassen sich mit solchen Sprachen auch die Lösungen effizient formulieren, sofern man sie beherrscht. Beispiele wie Lisp, Haskell oder Prolog und auch Smalltalk machen deutlich, dass das Beschreiben von Lösungen heute im Rahmen eines ganz anderen Gedankengebäudes ablaufen kann, als es ganz zu Beginn der technischen Entwicklung der Computertechnik üblich war.

Nun ist der Punkt erreicht, an dem sich oben skizzierter Schluss als Trugbild erweist: denn genau diese Programmiersprachen können auch nur effizient genutzt werden, wenn in den zugrunde liegenden abstrakten Begriffen gedacht wird, d.h. der Programmierer muss sich mit Theorien und Konzepten auseinandersetzen. Abstraktion ist daher nicht nur eine Erleichterung, sondern führt zu neuen fachlichen Anforderungen an den Softwareentwickler, sie wird zur Pflicht. Arbeitet man z.B. mit sogenannten funktionalen Sprachen, die der Mathematik sehr nahe stehen, so wird man früher oder später mit Konzepten wie Lambda-Calculus und Monaden konfrontiert, die der theoretischen Informatik entstammen. Damit wird der Programmierer doch wieder zum Spezialisten, nun nicht mehr für Bits und Bytes, sondern für abstrakte Konzepte der Informatik bzw. der Mathematik. Statt nun also Register usw. zu beherrschen, ist der moderne Softwareentwickler ein Meister der abstrakten Lösungswelten.

Dabei ist festzustellen, dass einige dieser abstrakten Sprachen schon zu den Zeiten von Bits und Bytes entwickelt wurden, allen voran Smalltalk und LISP. Entsprechend sind auch viele Konzepte schon weit vor dem Jahr 2000 in der Informatik bekannt. Ist das nicht ein Widerspruch zum eben Gesagten? Nein, denn es kommt noch ein weiterer wichtiger Aspekt dazu: der Aspekt des Gebräuchlichen, dessen was "fast alle" bis auf wenige Ausnahmen machen. Und das ist die eigentlich wichtige Tatsache: Nicht seit wann eine Programmiersprache existiert, sondern seit wann sie von der Mehrheit der im kommerziellen Umfeld stehenden Programmierer angenommen wird. So lässt sich tatsächlich beobachten, dass die oben angesprochenen Konzepte vermehrt in Literatur, Blogs und Diskussionen auftauchen. Und hier nun schließt sich der Kreis: Programmiersprachen mit einem theoretischen Konzept als Fundament ermöglichen die Formulierung von Problemlösungen im heutigen komplexen Wissensumfeld und sind daher zwingend. Die Entwicklung der Programmierwerkzeuge wiederum erlaubt es überhaupt erst, diese Programmiersprachen produktiv im kommerziellen Umfeld zu benutzen und bereitet somit deren breiten Einsatz.

Damit ist die Situation heutiger und zukünftiger Programmierer skizziert: Insofern wird also das Gedankengebäude des Entwicklers einfacher, weil moderne Entwicklungswerkzeuge ihm die Sorge um technische Details abnehmen. Die Problemlösung kann und muss in abstrakten Begriffen erfolgen, wodurch das Gedankengebäude niveauvoller wird, weil die Elemente der theoretischen Konzepte an sich eine intensive Beschäftigung und Vorbildung voraussetzen. Dies ist - zumindest im professionellen Bereich - keine Domäne des Gelegenheitsprogrammierers mehr. Und das führt nun zu den Anforderungen zukünftiger Programmierer.

Wesensmerkmale zukünftiger Entwickler

Wenn man nun der Frage nachgeht, wie man seine Ausbildung und berufliche Karriere als Softwareentwickler angehen will, so sollte man sich an dem eben festgestellten orientieren: Es wird immer weniger wichtig zu wissen, wie etwas gebaut wird. Das Handwerkliche, wie man eine solide Speicherverwaltung aufbaut, wie man ein Grafikpaket erstellt, wie man eine Datenbank anspricht, das alles ist höchstens noch für die Entwickler wichtig, die Entwicklungssysteme oder Betriebssysteme als Grundlage der Softwareentwicklungssysteme erstellen. Stattdessen wird es bedeutsam sein, sich geistig in abstrakten Welten bewegen zu können, mit den dort frei definierten Bausteinen des geistigen Modells kreativ Gebäude zu errichten, und auch die Grenzen einer gegebenen Bausteinsammlung zu erkennen.

Kurz gesagt: Die Systemarchitektur, verstanden als die Lehre der Bausteine und ihrer gefälligen und funktionalen Anordnung, ist der Schlüssel zukünftiger Entwicklungen. Es wird eine ganz zentrale Fähigkeit für den Softwareentwickler werden (bzw. ist es schon heute), ein Modell zu wählen, eine möglichst minimale Grundmenge an Bausteinen zu identifizieren und diese Bausteine wiederum mit den Bausteinen eines gegebenen Entwicklungssystems zu realisieren (Dies zeigt sich auch sehr deutlich in der Spielebranche: sogenannte Engines, also fertige Module für 3D-Grafik, KI oder Sound sind hier bereits gang und gebe).

Mit der Befreiung von technischen Details bietet sich auch ein neuer Freiraum für Kreativität. Heutige wie zukünftige Entwickler müssen diesen aber auch zu nutzen verstehen, denn Kreativität ist mitbestimmend für die Qualität der Lösungen. Alles andere wäre Verschwendung, schließlich wird noch lange kein Werkzeug und keine noch so mächtige Factory die menschliche Kreativität ersetzen können. Vielleicht wird Kreativität sogar der bestimmende Qualitätsfaktor für den Berufsstand und nimmt den Platz der Eigenschaft des technischen Expertentums ein.

Vom Programm zur Architektur

Ganz offensichtlich wird es für den Softwarearchitekten wichtig sein, sich mit den Begriffen des Gedankengebäudes auseinanderzusetzen, innerhalb dessen die zu lösenden Probleme liegen bzw. die die Welt des Kunden ausmachen. Es wird völlig unwichtig sein (höchstens für die wenigen Werkzeugbauer), wie ein Programm technisch zum Funktionieren gebracht wird. Es wird nur darauf ankommen, die Lösung des gegebenen Problems in geeigneten, kundenorientierten Begriffen kreativ zu lösen, wobei diese Begriffe Teil eines Entwicklungssystems sind, die völlig von der technischen Realisierung abstrahieren. Damit kann man hoffen, dass die Konzentration auf Bausteine, die die Welt des Kunden beschreiben, zu einer Software führen, die bestmöglichst dessen Wünsche widerspiegeln. Die Wendung von Programm zur Architektur.

Würde man aber auf die abstrakte Ebene problembezogener Begriffe verzichten, und sich ganz auf den Aspekt der Arbeitserleichterung durch Wizzards, Bibliotheken und Software Factories zurückziehen, so würde man viel Potential von Software (und Mensch) verschenken. Nach dem Motto: Jeder kann mit heutigen Werkzeugen Programme erstellen - aber kann auch jeder Architekturen entwerfen? Damit wird Erfahrung nach wie vor ein wichtiges Gut sein, denn Erfahrung spielt eine ganz wesentliche Rolle für das Fingerspitzengefühl, welche Architekturen tragfähig, technisch elegant und für den Benutzer schön sind und welche nicht.

Zum Schluss lässt sich, als Konsequenz der hier angestellten Betrachtungen, die Perspektive für Softwareentwicklung in Hochlohnländern mit einem Satz skizzieren: die Wandelung vom Softwareentwickler oder gar Gelegenheitsprogrammierer hin zum Softwarearchitekten.