*Horst-Joachim Hoffmann ist freier Mitarbeiter der COMPUTERWOCHE in München.

In gewisser Weise ist der Anwendungsentwickler einem Dolmetscher vergleichbar; die zu übersetzenden Botschaften bestehen dabei in den organisatorischen Strukturen des jeweiligen Unternehmens. Um diese Aufgabe zu erfüllen, muß der Programmierer diese Struktur verinnerlicht haben und im Kontext reproduzieren können.

Auch Software kann man hören, und zwar so: "... und dann springe ich in die Tabelle ..." Der Identifikationstransfer zwischen Schöpfer und Produkt bei einer Programmbeschreibung ist tiefgründiger Hinweis darauf, wie es in deutschen Landen mit der Programmierkultur bestellt ist. Die libidinös besetzte Beziehung zwischen Entwickler und seinem Werk gerät ins Wanken, aber: Tools und Datenbanken sind auch nicht der Weisheit letzter Schluß.

Die vielbeschworene Softwarekrise ist letztendlich die Krise einer Programmierkultur, folgt man den Aussagen vieler Experten dieses Fachbereiches. Untersuchungen konstatieren einen Einsatz von Sprachen der vierten Generation der nur knapp über 25 Prozent liegt - 75 Prozent der Entwickler also programmieren Cobol immer noch "zu Fuß". Historie, Fehlentwicklungen, eine verquere Bewertung des Produktes als solches, aber auch Aspekte des Selbstverständnisses von Programmierern und Entwicklern stehen einer radikalen Kur mit Aussicht auf Erfolg im Wege.

"Es ist ein Jahrhundertproblem, die Historie aufzuarbeiten und sich von der Erblast in diesem Bereich zu befreien", meint beispielsweise Gerd Kunzelmann, leitender Berater der Experteam GmbH aus München.

Das Problem der Programmierkultur stellt sich so auch als mehrdimensionales Gefüge zwischen den Komponenten Mensch, natürliche Umwelt, Unternehmen, Unternehmensumwelt und Technik mit allen Bauteilen der Datenverarbeitung dar. Die Ansätze zu einer Neuorientierung der Programmierkultur sind deshalb von fundamentalkritischen Anmerkungen begleitet, die ihren Ausdruck auch in leicht zynischen Fragestellungen finden: "Haben wir denn überhaupt schon eine Programmierkultur?" oder "Brauchen wir eine solche Kultur überhaupt?"

Kultur als Ausdruck gewünschter Verhaltensweisen unter bestimmten Konventionen hängt von Wertungen ab, die durch einen Qualitätsbegriff geschaffen werden müssen. Qualität aber insbesondere im Bereich der Software-Erstellung beinhaltet drei Ebenen - eine taktische, eine strategische und eine operationale.

Hier ist ein erster Ansatzpunkt für eine Analyse und Definition der Problematik gegeben: Bezogen auf ein Programm bedeutet diese Ebenendarstellung nämlich, daß der Ersteller ein x-beliebiges Programm mit ganz anderen Maßstäben bewertet als beispielsweise ein Mitglied der Geschäftsleitung - soweit so gut, doch hier eröffnet sich wohl ein Mißverständnis mit Tragweite.

Kultiviertes Benehmen im oben definierten Sinne bedeutet implizit, sich gemäß festgelegten Regeln zu verhalten, die geforderte Qualität - wie auch immer sie definiert sei - fördern.

Grundlegend betrachtet wird die Qualität von Software beeinflußt durch den Zweck des Ganzen: Aus Sicht des Entwicklers heißt es, ein wartbares technisches Produkt in die Welt zu setzen, aus Sicht der Geschäftsleitung, ein organisatorisch notwendiges Produkt funktionsbereit zu erhalten.

Für Hans Zinken, den Leiter Informationssysteme der Transatlantische Allgemeine Versicherung AG Hamburg, stellt sich die Frage der Programmierkultur als Gratwanderung zwischen dem theoretisch und dem wirtschaftlich Machbaren dar - die gute Mischung macht hier die Qualität. Kompromißloses Verfolgen einer theoretischen Linie habe allzu häufig dazu geführt, ökonomisch nicht tragbare Lösungen zu entwickeln, meint der Hamburger.

Die theoretischen Konzeptionen von Jackson bis CASE, so Zinken, sind in der Praxis vor Ort nie vollständig durchzuhalten, da die Software-Entwicklung vielerlei unternehmensbedingten Restriktionen unterliege. Auch Tools seien kein Allheilmittel, würden aber durch ihre Strukturierung helfen, ein Problem besser zu durchdenken - Programmierung ist in dem Hamburger Unternehmen begleitend zur Analyse angesiedelt.

Programmierkultur ist keine Frage, die sich allgemeingültig lösen oder eingrenzen läßt.

Software ist nach Ansicht von Experten letztlich nichts anderes als eine Randwertaufgabe mit Bedingungen, die in der Zeit variabel seien. Sowohl die Technik als auch die Aufgabe ändern sich, erläutert Gerd Kunzelmann. Da Eigenfunktionen und Eigenwerte existieren, ist es charakteristisch, daß nicht-triviale Lösungen nur für ganz bestimmte Bedingungen existieren.

Über die Software, so scheint es, muß unter fundamentalkritischen Aspekten in der Branche eine Einigung auf Grundsätzliches erfolgen. Die Tatsache, daß Software ein Programm ist, nach dem irgend etwas abläuft, führt bei den Betrachtungen nicht weiter. Software - und hier eine erste Hinwendung an Produktverständnis und damit auch Selbstverständnis derjenigen, die das Produkt erstellen - ist weit entfernt davon, als technisches Produkt im Sinne eines Kühlschrankes verstanden zu werden. In diesem Fall nämlich würde sie als Beschreibung einer Organisation geführt, die so formal streng ist, daß sie auch ein Computer versteht. Und dementsprechend ingenieurmäßig wäre sie entwickelt.

Hier liegt für Kunzelmann ein Ansatzpunkt, an dem umgedacht werden sollte: Software wird zu oft verstanden als schrittweiser Dienstbefehl an die Maschine - also im Sinne einer Vorschrift, was zu tun sei. Falsch, meint der Experte, denn global betrachtet wird nichts anderes getan, als bestimmte Dienst- und Arbeitsanweisungen aus der natürlichen Sprache in eine formale Sprache zu übersetzen und dabei eine Idiomatik einzusetzen, die in der jeweils anderen Welt gebräuchlich ist.

Software kann so als Dokumentation einer Organisation mit formal strengen Regeln verstanden werden. Der Programmierer muß zur Durchführung dieser Arbeit alles das, was vor dem Code steht, begriffen und verinnerlicht haben, reproduzieren und lokalisieren können, erweitern oder verringern - im Kontext wohlgemerkt.

Das Berufsbild eines Dolmetschers bietet sich für den Programmierer als Analogie an: Er empfängt eine Botschaft in einer (natürlichen) Sprache und muß die Bilder und Vergleiche, semantisch hinterfragen, um zu wissen, wie die Übersetzung in die Zielsprache sinngemäß korrekt ist.

Der Unterschied zu einer Fremdsprachenübersetzung besteht darin, daß die Randbedingungen bei Umsetzung einer natürlich-sprachlich formulierten Anforderung in ein technisches System eine "Dynamik der Veränderung" enthalten müssen.

Qualität im Softwarebereich bezieht sich langläufig auf Wartbarkeit, Änderbarkeit, Portabilität. Code gilt in diesem Bild als letzte Form einer Beschreibung, der andere Beschreibungen wie die fachlich orientierte oder die systemtechnische vorausgehen. Die Güte der letzten Beschreibung aber wird dadurch bestimmt, von welcher Qualität die Vorläufer sind - und sie werden immer besser, wenn man sich an Richtlinien, eine einheitliche Begriffswelt und Regeln hält.

Benötigte Information steht im Vordergrund

Im Laufe der DV-Geschichte kristallisierten sich zwei Arten der Erstellung von Programmen heraus. Zu unterscheiden ist zwischen der funktions- und der informationsorientierten Entwicklung.

Als klassisch gilt der Ansatz, mit der Frage "Was ist zu tun?" - also die Funktionsorientierung. Batchorientiert hat man die Daten dann so aufbereitet und organisiert, wie es für den Ablauf sinnvoll schien. Immer mehr dieser Inseln führten im Laufe der Zeit langsam, aber sicher zu einer Datenredundanz mit allen negativen Folgen für die heutige DV. Viele Häuser fahren noch Anwendungen ohne Integrationsaspekt und tragen so einen ballastgefüllten Softwarekorb mit sich herum.

Heutzutage steht die Information, die in einem Unternehmen benötigt wird, im Vordergrund - die logische Struktur und Abhängigkeit sind zu ermitteln, weil Funktionen sich typmäßig weniger ändern als die Verfahren, mit denen sie be- und verarbeitet oder erstellt werden.

Es sei sicher wichtig, so meint auch Zinken, mehr Zeit in die Analyse zu stecken, da für die reine Realisierung bereits gute Hilfsmittel zur Verfügung stünden. Das aber bedingt noch keinen Sonnenschein am Softwarehorizont, sondern lediglich die technische Verlagerung des Problems, so meinen andere Experten.

Bei der erlebten Veränderung des Enstehungsvorgehens setzt auch Michael Bauer, Geschäftsführer der Informatik Training GmbH, einem Unternehmen der Plenum-Gruppe aus Radolfzell, an. Die heutige Software-Entwicklung, so Bauer, bestehe aus den Phasen Konzeptionierung und Realisierung, wobei - berufsbildbezogen - der heutige Programmierer noch zu stark der Realisierungsphase zugeordnet werde.

Dem Code bei der Programmentwicklung kommt also im neueren Ansatz nur noch geringe Bedeutung bei - dennoch muß erneut auf die grundlegende Softwarefunktion und ihren Darstellungscharakter zurückgegangen werden.

Die Beschreibung in diesem Sinne als Code ist nicht nur formal streng, sie muß gegenüber dem technischen System auch vollständig in der Übermittlung von Anweisung inklusive Kontext sein - anders als bei einem natürlichen Empfänger, bei dem bestimmte Dinge vorausgesetzt werden können.

Die formale Dokumentation muß deshalb in der Tiefe "angemessen verwertbar" sein, wie Kunzelmann es umschreibt. Nicht der vielgepriesene Perfektionismus ist gefragt, sondern die angemessene Verwertbarkeit - und das heißt natürlich bei einem Computer etwas anderes als bei einem Menschen als Empfänger.

Die Qualität einer Kommunikation wird nun aber nicht nur dadurch bestimmt, was der Sender von sich gibt, sondern auch dadurch, was der Empfänger daraus macht.

Das Problem ist, daß der Computer "per se" überhaupt nichts verwerten, sondern nur ausfahren kann, weil ihm - die sogenannte KI ausgeklammert - grundsätzlich keine Bewertungsmöglichkeiten vorliegen. Aus diesem Grunde existiert schon rein logisch keine vollständige Anweisung. Veränderung ist einzuplanen.

Damit muß auch von einem weiteren beliebten Denkmodell Abschied genommen werden, nämlich der Einstellung, "Software sei etwas für die Ewigkeit". Aber auch die gegensätzliche Überlegung, daß Software zu einem bestimmten "Tag X" laufe und deshalb gut sei, führt bei den Betrachtungen zur Misere der Programmierkultur nicht weiter.

Die Programme sind für den Kurzzeiteinsatz schlicht zu teuer, und eine Organisationsbeschreibung - denn nichts anderes ist Software - kann als Investitionsgut nicht nach zwei Jahren wie ein gebrauchtes Auto weiter veräußert werden.

Die Zeitabhängigkeit als integraler Bestandteil der Qualität des Produktes ergibt sich, da Software eine gewisse Vorbereitungszeit benötigt und die Fähigkeit der Betriebsfertigkeit laufend geänderten Bedingungen angepaßt werden muß.

Gefordert wird laut Bauer seit einigen Jahren, mehr Sicherheit bei der Umsetzung der realen Welt in das Modell zu erreichen. Die Umsetzung "Modell in Durchführung" wird dabei durch vielfache Hilfsmittel und mannigfaltige Methodenschlenker unterstützt.

Ein Trick der angewandten Praxis besteht darin, Software so modular zu konstruieren, daß über Schnittstellen eine leichte Anpassung an geänderte Bedingungen vorgenommen werden kann. Das Denken in diese Richtung - oder auch das Erklären eines die Wartbarkeit fördernden Verhaltens als wünschenswert zu verstehen, ist, so Kunzelmann, ein Schritt zur neuen Programmierkultur: nämlich Software als ein technisches Produkt zu schaffen.

Dazu gehört natürlich auch der Gebrauch geeigneter technischer Mittel. Tools müssen her. Aber: Programmierer, so die Schelte aus den eigenen Reihen, begnügen sich nur allzuoft mit einem Editor und einem Compiler und lehnen es ab, weitere Methoden und ihren Gebrauch zu lernen.

Werkzeuge, die es gestatten, nach festgelegten Regeln bestimmte Darstellungstechniken für die zweifelsfreie Verständigung herzustellen, und die dadurch bedingte Aufgabe des Kopfmonopols (ich habe es verstanden; ob du es verstehst, interessiert mich nicht) bieten also zumindest aus rein technischer Sicht einen neuen Ansatzpunkt - bloß eingesetzt müssen sie werden.

Ein Teil der Selbstverantwortlichkeit und der "minderen" Kreativität kann beispielsweise durch Expertensysteme ersetzt werden. Diese Systeme beschränken sich von ihrer Auslegung her darauf, jedem Projektleiter, dem eine Vorgehensweise vorgegeben ist, Ansätze zur Verfügung zu stellen, lassen ihm aber gleichzeitig Raum, zu entscheiden, welche Möglichkeiten gewählt werden sollen.

Das Problem verlagert sich also weiter nach vorne in den Bereich der Konzeptionierung. Das Ziel ist die strukturierte Gestaltung von Datenmodellen, Ablauf- und Strukturmodellen. Hier aber ist durch Hilfsmittel meist wieder nur eine rein formale Überprüfung möglich.

Zur Frage der Veränderung der Kultur hat Kunzelmann eine philosophisch begründete, klare Aussage parat: Es sind letztlich die Menschen selbst, die ihre Kultur bestimmen.

Der Experte hat auf Grund einer Untersuchung über den Einsatz von Tools die - eigentlich überraschende - Erkenntnis gewonnen, daß sich die Leute, die mit der Erstellung von Software befaßt sind, grundsätzlich zu wenig Gedanken über die Organisation ihrer eigenen Arbeit machen. Oft fehle das Bewußtsein, daß es sich bei der Software-Erstellung "lediglich" um die Produktion eines hochwertigen komplexen Produktes handele.

Viele Softwerker, so die Ergebnisse der Untersuchung, könnten zwar Fachfunktionen informationstechnisch darstellen, darauffolgend aber träte das Phänomen des Pädagogen auf, der bei der Erziehung der eigenen Kinder versage.

Unbestritten ist, daß die Analyse im Gegensatz zur reinen Programmierung ein sehr stark kreativer Prozeß ist. Leider, so Bauer, unterliegen die Methoden, die diese Arbeit systematisieren, häufig Akzeptanzproblemen. Tools in diesem Bereich aber seien dennoch dabei, sich langsam durchzusetzen.

Unvoreingenommene Technologiegläubigkeit allerdings ist ebenfalls kritisch zu bewerten. Mangels selbstkritischer Analyse der Arbeit nämlich, so Kunzelmann, entstehe doch hie und da der Eindruck, es fehle nur irgendein Werkzeug zum Programmierglück.

Aus der Historie heraus ist klar, daß zu viele eingefahrene Methoden über die Jahre mitgenommen wurden - das Altlastenproblem scheint unlösbar. Auch Zinken als Praktiker plädiert für eine Neufassung von Programmen, bevor sie wartungsunfähig werden.

Zudem ist in der täglichen Praxis hinderlich, daß bei vielen Unternehmen der kreativere Teil des Potentials durch Wartungsarbeiten gebunden ist. Diese seien wiederum deshalb so ineffizient, weil die Software so schlecht sei. Der Grund: Wartungs- und Änderungsanforderungen wurden ehedem bei der Konstruktion der Software nicht berücksichtigt. Die Software wurde nicht ingenieurmäßig konstruiert, sondern mehr oder weniger kreativ spontan nach irgendwelchen Vorgaben gefertigt.

Als gegeben gilt: Tools zur Konzeptunterstützung sind vorhanden, die reine Programmierung als Codierung könnte automatisiert werden. Dennoch ist die Misere greifbar - der Sündenbock ist diesmal der Mensch, das von ihm selbst so viel gepriesene "Maß der Dinge". Methoden verlangen auch immer ihre Beherrschung in Form von Kenntnissen, Akzeptanz und Disziplin - und hier scheint es zu haken.

Hinderlich ist auch, daß viele DVler den angebotenen Tools nicht trauen, wie zu hören ist, oder sich bei der Auswahl unsicher fühlen, so daß sie Selbstgestricktes zur Unterstützung ihrer Arbeit einsetzen. So ergibt sich im Laufe der Zeit ein ganz eigenes System, das aber wiederum an Grenzen stößt - die Ansprüche an den Komfort steigen, die Wartung und der Upgrade eigener Hilfsmittel kostet kreative Kraft.

So ergeben sich beim Einsatz von Tools Probleme teils aufgrund der Auslastung, teils aber auch durch Fehler der Unternehmenspolitik an sich. Die tägliche Praxis kennt durchaus Fälle, wo Weiterbildungsmaßnahmen im wahrsten Sinn des Wortes unterdrückt werden, um nicht einer Unzufriedenheit mit den aktuellen, auch historisch gewachsenen Gegebenheiten Vorschub zu leisten.

Die zusätzliche Gefahr in solchen Fällen ist, daß die doch ausgebildeten Mitarbeiter nach Erkennen ihrer Situation das Unternehmen verlassen. Eine Erneuerung von außen findet insofern nicht statt, denn auch Wissensvorsprung kann zu einem Außenseiterdasein führen. Einem gewissen missionarischen Eifer wird hier durchaus innerhalb der Branche Bedeutung beigemessen, denn nicht nur die Mitarbeiter leiden unter trägen Vorgesetzten - auch umgekehrt.

Vor gut 15 Jahren übrigens, so erinnert sich Bauer, gab es eine große Umstellungswelle von Assembler auf Cobol, die ähnliche Probleme hervorrief. Dieses Verhalten tritt immer dann auf, so der Ausbildungsprofi, je mehr neue Methoden Denk- und Verhaltensmuster ändern.

Die "ausgefeilten" Werkzeuge, die am Markt sind - also nicht reine Generatoren von einer Zielsprache in eine andere -, unterstützen (und das wird leicht vergessen) zum großen Teil primär die Beschreibungs- und Darstellungstechnik, aber nur ansatzweise den kreativen Teil der Software-Entwicklung mit Anleitung und nachträglicher Kontrolle. Letztlich dienen sie also dem Umsetzen dessen, was im Kopf entstanden ist in einer verständlichen Form, auf deren Grundlage Prüfung und Abgleichung erfolgen kann.

Krise der Programmierkultur

Das Trauma der Komplexität, das Gefühl der Unentbehrlichkeit, das Monopol des Kopfes, der Nachweis, benötigt zu werden - Kriterien, die zur Softwarekrise und heutigen Programmierkultur beitragen. Durch zunehmende Automatisierung werden dem Menschen laufend Bereiche genommen, auf denen er sich unentbehrlich fühlen kann - im Bereich der Computerei konkurrieren viele Menschen durch ihr Erinnerungsvermögen und ihre Merkfähigkeit noch mit der Maschine und halten sich so für unersetzbar.

Die psychologischen Krücken, die eingesetzt werden, aber auch strenge Regeln bei der Software-Erstellung, beschneiden - vermeintlich - den Menschen in dem, was er selbst für den besonderen Wert seiner Person hält. Wenn dann auch keine Führungskonzepte vorhanden sind, die dieses Verantwortungsdefizit ausfüllen und in kreatives Potential umsetzen, steht der Frust ins Haus.

Das halbe Programm bereits im Kopf

Der Widerspruch zwischen Kreativität auf der einen Seite und Normen und Regeln auf der anderen ist nur scheinbar - das persönliche Dilemma, das hieraus erwächst, kann aber nur dann gelöst werden, wenn das notwendige Selbstverständnis da ist. Das Selbstwertgefühl sollte nicht daraus resultieren, daß der Software-Entwickler behaupten kann, daß gewisse Dinge nur ihm bekannt sind. In mindestens 50 Prozent der bundesdeutschen Unternehmen, die Mainframes einsetzen, hat der Programmierer 50 bis 80 Prozent des später Programmierten im Kopf oder besitzt lediglich eine ungenaue verbale Vorgabe, besagen inoffizielle Zahlen aus der Branche, da sich die Unternehmen hier mit konkreten Aussagen sehr bedeckt halten.

Dem Programmierer kommt hier ein hohes Maß an Verantwortung bei der Umsetzung zu, wobei - auch das wird aus der Praxis bestätigt - teils auch Fachfunktionslösungen dem Anwender durch die DV-Profiseite vorgegeben werden. Der Qualitätsbegriff sollte, so die Forderung, so aufgebaut werden, daß eine Arbeit als dann gut bezeichnet wird, wenn sich die eigenen Vorstellungen mit dem Qualitätsbegriff der Unternehmung decken, meint Kunzelmann.

Das Selbstverständnis des oben erwähnten Dolmetschers müßte sich dann darauf beziehen, sich gut zu fühlen, wenn die Übersetzung frei von eigenen Werten erfolgt ist - in der Programmierung, so der Tenor der geführten Gespräche, ist häufig der gegenteilige Ansatz zu finden: Anwender und Maschine sind untergeordnet, der Programmersteller fühlt sich als Mittelpunkt, denn ohne ihn läuft gar nichts.

Hier empfiehlt Bauer, die Tool-Auswahl als den letzten Schritt zu sehen, der gemacht wird. Der erste Schritt sei, sich über die methodischen Erfordernisse im klaren zu sein, auch unter Berücksichtigung der Mitarbeiterstruktur. Als zweiter Schritt folgt die organisatorische Überlegung mit betriebswirtschaftlichem Aspekt - dann erst steht die Frage ins Haus, welches Tool das optimale sei.

Ähnliches gilt für die inhaltliche Strukturierung der Programmieraufgaben.

Unter dem informationstechnischen Ansatz, der langsam Raum greift, heißt es, zuerst ein Informationsmodell aufzustellen und physisch abzubilden, bevor programmiert wird. Das bedeutet, wie es scheint, für viele Unternehmen eine Umkehrung um 180 Grad in der Software-Entwicklung.