Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

15.07.1983

Programmierer: Cool gegenüber dem Tool

Der Normalprogrammierer, dies das landläufige Vorurteil, arbeitet "comme ci, comme ca", so lala, grad wie es ihm in den Methodenkram paßt - "schlampig", sagen die Gralshüter des theoretischen Software-Engineering. Haben alle Programmierer ein dickes Fell? Sicher nicht. Aber alle Programmierer sind Programmierer. Und die Programmierer hatten zwanzig Jahre lang Künstlerfreiheit. Praktiker wissen, daß diese Freiheit auch weidlich ausgenutzt wurde. Gegenteiliges ist jedenfalls nicht bekannt. Also müssen sich die "soften" DV-Männer die Jacke (siehe oben) auch anziehen.

Angesichts der zunehmenden Benutzeranforderungen (Stichwort "Partizipation") kann das "Go slow, aber schööön" zu einem Applikations-Chaos führen. Die Folge kann ein Konflikt zwischen DV-Abteilung und Fachbereichen sein, den niemand zu lösen imstande wäre. Wie ist das zu verhindern?

Eins ist sicher: Gefahrensignale ("Anwendungsstau" , "Gap von zwei Jahren") orteten Weichware-Profis schon früh. Man müsse, warnten Programmier-Experten bereits Anfang der siebziger Jahre, eben Tools einsetzen, Werkzeuge, die zu systematischem Arbeiten zwingen, die aber auch das Programmieren selbst vereinfachen und damit effizienter, wirtschaftlicher machen. Um so verwunderlicher ist es, wie lasch Software-Manager bei den Anwendern offenbar die Mittelverwendung für die Systementwicklung handhaben. Da vergammeln viele Programmierwerkzeuge in den Schubladen der Softwerker, dienen als Alibi für vermeintlich rationelles Computern.

Nun können sich die meisten Software-Propheten nicht vorstellen, daß 1990 noch "line per line" in Cobol kodiert wird. Zu denen, die sich für neue Supertools stark machen, gehört auch die Sperry GmbH. "Mapper" heißt die Metasprache des Mainframe-Anbieters, eine Mischung aus "4th Generation language" und Datenbanksystem, wenn man die Sperry-Werbung richtig interpretiert - kurz: eine "Bombe". Mapper soll auch den Nicht-Spezialisten ansprechen, der Ad-hoc-Anwendungen, Überfall-Abfragen, am eigenen Terminal abwickeln will. Alle Befürchtungen, der Lernaufwand für ein derartiges Benutzertool sei zu hoch, suchen die Mapper-Väter mit der Aussicht auf eine spürbare Entlastung der zentralen Anwendungsentwicklung zu zerstreuen.

Doch Mapper war für Sperry bisher alles andere als ein Erfolg - der Durchbruch wurde nicht geschafft. Jetzt will man dem Produkt mit einer neuen Marketingstrategie Beine machen: Eine eigene Mapper-Crew vertreibt das "Superding" auch bei Nicht-Sperry-Kunden. Zweifel an der Durchschlagskraft dieser Maßnahme sind gleichwohl angebracht. Im Grunde hat sich die Situation auf dem Softwaremarkt nicht verändert. Hier reicht das Argument von der "einfachen" Programmierung nicht aus, so schlüssig es in sich auch sein mag. Es ist wohl aber eine Fehleinschätzung, den Programmierern - und denen, die sie lenken - generell Tool-Ignoranz vorzuwerfen. So einfach liegen die Dinge nicht. Das größte Rationalisierungspotential, das wußten schon die alten Cobolianer, steckt nicht in der Programmierung selbst, sondern in einer inhaltlich wie formal "richtigen" Anwendungsbeschreibung, ergibt sich vor der eigentlichen Programmierung, im Systementwurfsstadium, bei der Projektplanung, mit anderen Worten: durch eine "gute" Programmiervorgabe. Geht diese am Problem vorbei, kommt trotz Tool - Garbage heraus, Murks mit dem Charakter einer Zeitbombe. Verständlich, daß Profis cool bleiben.

_AU:Dieter Eckbauer