Jan Witt, Abteilungsleiter bei PCS, München

Es gab Zeiten, da glaubte man, der Beruf der Telefonistin, der Beruf des Chauffeurs oder des Fotografen seien sehr zukunftsträchtig. Zugrunde lag die Annahme, daß mit dem Anwachsen der Zahl der Telefone, der Automobile oder der Fotoapparate auch die Zahl derer anwachsen werde, die sich als Fachleute auf den Umgang mit diesen Innovationen verstehen. Wir wissen heute, daß automatische Telefone, Selbstfahrer und Selbstfotographierer dafür gesorgt haben, daß sich diese Vermutung nicht bestätigt hat. Es gibt zwar berufsmäßige Telefonfachleute, Chauffeure und Photografen, aber doch nicht in dem Umfang und in den Rollen, die man sich damals vorgestellt hatte.

Wie verhält es sich nun mit den Software-Herstellern, deren Produkt obendrein beliebig vervielfältigt werden kann und das keinen Alterungs- und Verschleißerscheinungen unterworfen ist? Seit über 20 Jahren haben Hochschulen, Fachhochschulen und die verschiedene Ausbildungseinrichtungen die Berufswelt mit ausgebildeten Software-Entwicklern eingedeckt. Dazu gibt es eine große Anzahl von Naturwissenschaftlern, Ingenieuren und Kaufleuten, die den Umgang mit Software auf irgendeine Weise gelernt haben. Nicht allen von ihnen sind Möglichkeiten der beruflichen Weiterbildung gegeben, und es scheint durchaus angemessen, die Frage zu stellen, was auf Dauer eigentlich aus dem Beruf des Software-Entwicklers werden soll.

Die Vergangenheit war folgendermaßen:

- Die Software-Entwickler gingen mit ziemlich teurem und verhältnismäßig knapp verfügbarem Gerät um

- Sie waren sehr oft genötigt, "aus dem vollen zu fräsen", Insellösungen ohne geeignete Vorlagen und mit nur wenigen signifikanten Schnittstellen zur externen Welt zu realisieren.

- Dort, wo sie gleichwohl Schnittstellen benötigten, fehlten meist entsprechende nationale oder internationale Standards, so daß auch bei diesen Schnittstellen ihre Erfindungsgabe gefragt war.

Schwerpunkte waren dabei die Neuschaffung von Software, Großprojekte mit erheblichem Infrastrukturbedarf, kleine Auflagenziffern ("Maßanzug"), Optimierung der Betriebsmittelnutzung und relativ überschaubare Quellcode-Mengen.

Die Gegenwart sieht so aus, daß

- das Gerät (die Hardware) im Regelfall billig beschaffbar und im Prinzip unbegrenzt verfügbar ist,

- Softwarelösungen in eine existierende technische Hardware- und/oder Softwarewelt nebst dazu passender Organisation hineinentwickelt werden müssen; hierbei ist eine Fülle von Schnittstellen zu beachten,

- viele wichtige Schnittstellen internationalen De-iure- oder De-facto-Normen folgen, die rigoros eingehalten werden müssen,

- Großprojekte ohne Vorgänger und/oder Vorlage sind sehr selten geworden,

- Portieren, Anpassen, Integrieren gegenüber der Neuentwicklung dominieren,

- Schwerpunkte dabei hohe Auflageziffern, riesige Quellcode-Volumina und komplexe Konfektionierungsmechanismen sind.

Was macht der Software-Entwickler morgen? Wenn man über die Tätigkeit des Software-Entwicklers diskutiert, muß man sich natürlich auch die Frage stellen, was denn nun der unverlierbare Kern dieser Tätigkeit sein könnte. So wie der Schneider heute häufig nur noch ein Änderungsschneider ist, der Schuster ein Flickschuster, so muß man sich zum Beispiel die Frage stellen, ob der Software-Entwickler der Zukunft nicht eher ein Softwareflicker und -reparateur sein wird als ein Neuhersteller von Software.

Wenn man das neue Schlagwort von der Software-Wiederverwendung, dem "Software Reuse", ernst nimmt, so muß man ja auch an den Gebraucht-Softwaremarkt, ja an den Second-hand-Softwareladen denken. Hier stellt sich dann die Frage, was denn mit der existierenden Software geschehen wird. Software ist zwar keinem Verschleiß unterworfen, muß aber, wie wir wissen, trotzdem "gewartet" werden.

Wird man zukünftig wartungsarme, gar wartungsfreie Software entwickeln können? Wird diese auf den Paradigmen des logischen Programmierens und/oder des objektorientierten Entwurfes basieren? Wird neue Software die alte völlig substituieren?

Es ist vielfach darauf hingewiesen worden, daß der Software-Entwickler sich selbst möglicherweise ums Brot bringt, sich und seinesgleichen wegrationalisiert.

Sollte sich zum Beispiel herausstellen, daß es in der Tat vermeidbar ist, daß wieder einer zum 155ten Male das fünfeckige Rad erfindet, so wäre dies nur dann ein harter Schlag für den Betreffenden, sofern er sich auf nichts anderes als auf das Erfinden eckiger Räder versteht. Etwas ernsthafter gelangt man zu drei möglichen Prognosen:

1. Der Bedarf an Software-Entwicklern nimmt ab, weil alle benötigte Software schon existiert und via Wiederverwendung genutzt werden kann.

2. Die Software-Entwicklung kann von jedermann selbst ausgeübt werden.

3. Die "Künstliche Intelligenz" wird die Software-Entwicklung überflüssig machen.

Falls eine der beiden ersten Varianten tatsächlich eintreten sollte, hängt es von der Bandbreite des Bildungs- und Erfahrungshintergrundes des einzelnen ab, ob er deshalb um seinen Job fürchten muß.

Es geht dabei vor allem um die Frage, ob sich der Entwickler als Universalist oder als Spezialist versteht und betätigt. Wichtig ist dabei, sich klarzumachen, daß die Softwaretechnik stets darauf abzielt, mehr noch als viele andere Disziplinen, die Dinge ein für allemal zu lösen, und zwar dadurch, daß an die Stelle des konkreten Arbeitsablaufes das Verfügbarmachen eines Verfahrens tritt.

Wenn wir sagen "ein für allemal lösen", so lohnt es sich auch, noch ein bißchen über den Stellenwert der eigentlichen Informatik, das heißt der Kerninformatik im engeren Sinne im Vergleich zur Informationstechnik oder Informationstechnologie im weiteren Sinn nachzudenken.

Es gibt heute sicherlich in der Welt nur wenige Leute, die die Chance haben, einen Automobilmotor neu zu konstruieren, der dann tatsächlich in einer größeren Anzahl von Autos eingesetzt wird. Gleichwohl ist es überaus nützlich, gelernt zu haben, wie man einen solchen Motor konstruiert, und zu wissen, warum die handelsüblichen Konstruktionen in welcher Weise entwickelt wurden. Viele technische Produkte, wie zum Beispiel auch das Fahrrad, erfahren nach ihren stürmischen Anfangsjahren eine gewisse Stabilisierung, die für alle Personen, die mit diesem technischen Gegenstand umgehen, also Verkäufer, Käufer, Benutzer und Reparateure, eine faktische Situation festschreibt, die durch keine noch so klare Entwicklergroßtat mehr beseitigt werden kann.

Eine ähnliche Stabilisierungstendenz besteht heute auch für viele Softwaresysteme, beginnend bei den Betriebssystemen und Compilern und endend bei einer Vielzahl von Standardapplikationen. Natürlich werden Produkte durch das Hinzufügen neuer Funktionen ergänzt, und wird es auch gelegentlich ein völlig neuer Kern substituiert. Dies geschieht aber stets mit dem Vorbehalt, daß der Benutzer, der bei Einsatz des erweiterten Produktes lediglich fortfahren will, etwas zu tun, was er bisher getan hat, von innovationsbedingten Änderungen weitmöglich verschont wird.

Wenn der Software-Entwickler weiterhin eine begehrte Arbeitskraft bleiben will, muß er als Designer und Implementierer für eine Zielgruppe von Benutzern diesen Umstand berücksichtigen.

Ein Software-Entwickler sollte genauso auf dem Gebiet der Produktentwicklung wie auch auf dem Gebiet der Projektentwicklung erfolgreich sein. Um dies sicherzustellen, ist die Auseinandersetzung mit einigen wichtigen Innovationstrends unerläßlich:

- Anforderungs-Spezifikationen werden ergänzt durch Benutzungsprototypen (Projektentwicklung).

- Glanzbroschüren (sogenannte Papiertiger) sind zu ergänzen durch Akquisitionsprototypen (Projektentwicklung).

- Theorie und Praxis von Parallelismus, objektorientierter Implementierung mit Klassenbibliotheken, Programmieren mit Logik etc. werden begriffliches Standardrepertoire.

- Der strenge Nachweis der Softwarezuverlässigkeit hat seinen Preis, den jedoch inzwischen viele zu zahlen bereit sind.

Also, als Software-Jobkiller hat die Künstliche Intelligenz bisher noch nicht gewirkt. Statt dessen scheinen die Zauberlehrlinge beim Ausbremsen ihrer bockigen Besen eher einer selbstverordneten Beschäftigungstherapie zu frönen. Wenn irgendwer Sorgen haben muß, dann ist es der gelernte Wissensingenieur, der der Fachabteilung den Nerv tötet und vom Softwareprofi nicht ganz für voll genommen wird. Das heißt nicht, daß der Bedarf an kompetenten Leuten, die dem Endbenutzer den Puls zu fühlen verstehen, nicht steigt.

Gefragt sind eher ein solides Datenbankdesign und eine vernünftige Benutzeroberfläche als eine hochgezüchtete Wissensbasis. Notwendig sind Leute, die es verstehen, die Dinge richtig zu benennen und sich in Wort und Schrift präzise auszudrücken. Man darf nicht vergessen, daß begriffliche Schlamperei gerade in Anwendungsbereichen mit feingeschliffener spezifischer Terminologie mehr Schaden anrichten kann, als die künstliche Entwicklerintelligenz wieder gutzumachen verstünde.