Das Vorzeige-Objekt der Propheten moderner Software-Technologie ist das vielzitierte New-York-Times-Projekt, die Fertigstellung eines Information Retrieval Systems durch die IBM, konsequent nach Methoden wie Chief Programmer Team Konzept, Top Down Design, Strukturierte Programmierung und Verwendung der datenorientierten HIPO-Diagramme statt der ablauforientierten Flußdiagramme. Zu erstellen waren 82 000 Programmzeilen, Durchschnittsleistung pro Mann-Jahr, (11 Monate): 6900 Lines of Code. Demgegenüber werden verschiedene Vergleichswerte ähnlicher Projekte aus der Literatur zitiert, die von 2000 bis 3000 Programmzeilen schwanken.
Diese spektakuläre Produktivitätssteigerung rechtfertige nicht - so wird vielfach eingewandt - die Verallgemeinerung, daß generell durch die neuen Verfahren ein derartiges Übersoll erreicht werden kann. Zum einen dürfte es sich bei dem IBM-Team aus Top-Leuten weit über Durchschnittsqualifikation gehandelt haben, zum anderen werde selten nur ein Projekt "auf der grünen Wiese" hochgezogen. Vielfach sei bis zu 80 Prozent aller Programmierarbeit in der Praxis Wartung, Verbesserungen, Erweiterungen im Rahmen der vorhandenen, anders gefertigten Strukturen.
Schon wieder eine Revolution
Praktiker sind skeptisch gegenüber den vielgepriesenen Verfahren der "Neuen Software-Generation". Ihnen wurden schon zu viele Generationen und Revolutionen versprochen, so daß diese Begriffe ziemlich abgenutzt sind. Der gängigste Einwand ist: Dergleichen machen gute Leute schon immer so.
Stichwort Modularisierung: Selbstverständlich wird vielerorts längst modular programmiert. Aber die "konventionelle Modularisierung" ist nach Vorgabe des Datenfluß-Planes ablauforientiert und fertigt zeitlich nicht logisch aufeinanderfolgende Einzelmodule, die eben nicht Subsysteme hierarchisch übergeordneter Aufgabenstellungen sind und mit diesen nur eine einzige eindeutige Schnittstelle haben. Konventionelle Moduln haben nicht Funktionen, sondern Datenstrukturen als Schnittstellen - und davon meist mehrere.
Das ist mehr als Haarspalterei, sondern ein entscheidendes Argument gegen den Einwand, Top Down und dergleichen sei nur "alter Wein in neuen Flaschen".
Es zeugt von vorsätzlichem Desinteresse, in der Strukturierten Programmierung nur die Vermeidung des GOTO zu sehen (das es ja auch dort an den richtigen Stellen noch gibt) und das neue Verfahren damit abzutun, daß gute Programmierer eben keine Spaghetti-Programme schreiben. Das neue an der Strukturierten Programmierung ist das Korsett (Nasi-Shneidermann-Diagramme/Struktogramme), das allen Freistil-Künstlern angelegt wird und sie zwingt, so zu programmieren, wie es die guten Leute immer schon taten. Des weiteren die Möglichkeit, auch die weniger qualifizierten Mitarbeiter mit relativ geringem Schulungsaufwand zu Bestleistungen zu bringen. Schließlich wären noch die Vorteile für die Dokumentation zu erwähnen.
Verfügbares Know-how auch nutzen
Auch das Chief Programmer Team Konzept ist so neu nicht. Und überall schon hat man die weniger qualifizierten Mitarbeiter für in sich möglichst (!) abgeschlossene, leichtere Aufgaben eingesetzt. Nur, selbst die leichten Aufgaben wurden vielfach sehr komplex, weil sie bei konventioneller Modularisierung mit zahlreichen anderen Systemkomponenten korrespondieren. Anders, wenn nach dem Verfahren der schrittweisen Verfeinerung vorgegangen wird - vom problemnahen Gesamt-Design zur maschinennahen Detail-Ausführung.
Entscheidend wäre die Einsicht, daß das Hauptproblem - bei unübersichtlichen 5000 Befehle-Programmen anders als bei überschaubaren 500-Befehlen - nicht das Programmieren eine Programmvorgabe ist, sondern die Lösung einer komplexen Aufgabenstellung. Das klingt banal? Nur die wenigsten erst haben daraus die organisatorischen und methodologischen Konsequenzen gezogen. Es wird zu wenig vom verfügbaren Know-how Gebrauch gemacht.