2.2 Kritik von Zeitgenossen

Während die Fabrikanhänger vorwiegend Mängel in der Umsetzung monierten, formulierten einige Experten grundsätzliche Einwände.

„Software Factory“ kontaminiert

Nach den üblichen „Success Stories“ in der frühen Phase überschritt der Hype-Cycle 1991 seinen Kulminationspunkt. Wenige später war das Scheitern so offensichtlich, dass niemand mehr etwas von „Software Factories“ wissen wollte.

Einige Unentwegte widmeten sich noch der Ursachenforschung: Die Tools seien zu proprietär und nicht flexibel genug gewesen, sie hätten auch nicht durchgängig alle Phasen des Entwicklungsprozesse abgedeckt, die Unterstützung bei der Wartung, beim Reengineering und bei der Wiederverwendung sei schon wegen mangelnder theoretischer Konzepte nicht möglich gewesen. Organisatorische Aspekte und das Controlling seien oft vernachlässigt worden. Best Practices als Basis für Standards hätten gefehlt.

Es kamen aber auch grundsätzlichere Fragestellungen zum Vorschein. Die Anzahl der Programmzeilen als Maß für Projektfortschritt und -umfang hatte sich als untauglich erwiesen. Da sich Softwareprozesse „nicht einfach als Wiederholprozesse auffassen“ ließen, bereite die Quantifizierung Probleme. Es sei unklar, ob und wie sich Softwareprozesse überhaupt unter statistische Kontrolle bringen ließen. Womöglich sei die Fabrikanalogie doch nicht angemessen, das deute sich bei der Betrachtung von Risiken an: Hier gebe es grundsätzliche Unterschiede, Replikationsrisiken im Produktionsprozess, aber Konstruktionsrisiken in der Softwareentwicklung.

Selbst bei Anhängern des Fabrikkonzepts dämmerte die Erkenntnis, dass Softwareentwicklung etwas eigenes ist:

„Gesucht ist daher ein angemesseneres Modell, bei dem die Prozesse weder Einmalprozesse noch reine Wiederholprozesse sind. Es ist unwahrscheinlich, dass man ein solches vorbildhaftes Modell für den Softwareprozess von einem anderen Prozess ableiten kann.“ (Herzwurm et al., 1994, s.11)

Eine Weisheit der Dakota-Indianer besagt: „Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab!“. Nicht so die unbelehrbaren Industrialisierer, sie geben dem toten Pferd einen neuen Namen. Das tote Pferd „Software Factory“ nennen sie jetzt „Prozessorientierung“.

„Die Fabrik scheint nicht mehr das Vorbild der Softwareproduktion zu sein. Dennoch zeigt sich bei genauerer Betrachtung, dass sowohl das Ziel, Softwareprozesse wie Fabrikprozesse zu beherrschen, als auch die Fabrikanalogie, Softwareprozesse wie Fabrikprozesse zu betrachten, im wesentlichen weiterhin bestehen. … Allerdings wird die Verbesserung der organisatorischen und methodischen Rahmenbedingungen der Softwareentwicklung nicht mehr unter dem inzwischen als kontaminiert geltenden Begriff Software Factory betrieben, sondern unter den Begriffen: Prozessorientierung, Total Quality Management etc.“ (Herzwurm et al., 1994, s.1)

Bei den Anhängern des Fabrikkonzepts schimmert die Fragwürdigkeit des Ansatzes durch, unvoreingenommene Experten kritisieren das Konzept grundsätzlich.

Fundamentalkritik

Peter Naur hatte bereits 1985 die Analogie zur Industrieproduktion kritisiert:

„More generally, much current discussion of programming seems to assume that programming is similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily. Another related view is that human beings perform best if they act like machines, by following rules, with a consequent stress on formal modes of expression, which make it possible to formulate certain arguments in terms of rules of formal manipulation. Such views agree well with the notion, seemingly common among persons working with computers, that the human mind works like a computer. At the level of industrial management these views support treating programmers as workers of fairly low responsibility, and only brief education.“ (Naur, 1985)

Peter Naur sah Programmierung als Theoriebildung. Diese sei nur von hochqualifizierten Profis zu leisten:

„On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. Instead the programmer must be regarded as a responsible developer and manager of the activity in which the computer is a part. In order to fill this position he or she must be given a permanent position, of a status similar to that of other professionals, such as engineers and lawyers, whose active contributions as employers of enterprises rest on their intellectual proficiency.“ (Naur, 1985)

Derlei Einsichten bleiben Beratern und Managern bis heute verwehrt, wenn sie ProgrammiererInnen als austauschbare Ressourcen sehen. Genauso wenig dürften ihnen die klaren und leider wieder aktuellen Worte von Tom DeMarco aus dem Jahre 1993 gefallen. Mit Fabrikmethoden lasse sich bestenfalls schlechte Software erstellen:

„Ich halte es für grundfalsch und kontraproduktiv, Software mit Fabrikmethoden zu produzieren. Organisationen, die gute Software entwickeln, wissen, dass Softwareentwicklung eine Forschungs- und Entwicklungsaktivität ist, keine Produktionsaktivität. Organisationen, die versuchen, eine Produktionsaktivität daraus zu machen, produzieren schlechte Software (wenn auch möglicherweise viel davon).“ (Tom DeMarco, 1993)

Software Factories ignorierten die eigentlichen Probleme der Softwareentwicklung:

„Software Factories tun alles, um ihre Projekte zu beschleunigen, und nichts, um sie in die richtige Richtung zu lenken. Damit aber ignorieren sie die wahren Probleme unserer Arbeit. Sie schaden mehr als sie nützen: Indem sie die Mitarbeiter auf Auto-Pilot stellen, schalten sie unseren wichtigsten Kontrollmechanismus ab.“ (Tom DeMarco, 1993)

Automatisierung begrüßte DeMarco als Entlastung von Routinetätigkeiten:

„Wenn wir alle Elemente der Software-Produktion automatisiert haben, die deterministisch sind oder deterministisch gemacht werden können, ist der Softwareentwickler mehr mit konzeptuellen Aufgaben befasst als je zuvor. Er hat nichts mit einem Fabrikarbeiter gemeinsam. Am Ende werden wir etwas viel Sinnvolleres erreicht haben als eine Software Factory es je erreichen könnte: Die Entpflichtung des Softwareentwicklers von Routinetätigkeiten.“ (Tom DeMarco, 1993)

weiter

Eine Antwort to “2.2 Kritik von Zeitgenossen”

  1. vaba Says:

    „Peter Naurs Sichtweise auf das Programmieren ist gefährlich. Für Naur ist das wichtigste Ergebnis des Programmierens nicht die Erzeugung von Programmtext und Dokumentation, sondern die Bildung von Theorien zur Lösung des jeweiligen Problems. Eine derartige Theorie liegt jedem Programm implizit zugrunde. Man muß sie verstehen, um das Programm erfolgreich erweitern und anpassen zu können. Doch dieses Verständnis kann nicht aus Quellcode und Dokumentation allein gewonnen werden; der persönliche Austausch mit den ursprünglichen Programmierern ist dafür unabdingbar. Ein Programm, das von seinen ursprünglichen Entwicklern verlassen wurde, ist tot; es kann von einem anderen Team nicht konsistent weiterentwickelt werden.

    Naurs Sicht ist gefährlich für Firmen, die damit in Abhängigkeit von ihren
    Programmierern geraten. Sie können nicht mehr einfach eine Programmiererin oder ein Programmierteam durch andere ersetzen, ohne um ihre bisherige Software fürchten zu müssen. Das »Software Engineering« entstand gerade mit dem Ziel, diese Abhängigkeit zu vermeiden, die Softwareentwicklung vom Individuum zu lösen. Häufig richteten sich die Texte zur Popularisierung des Software Engineerings
    sogar explizit an Manager mit dem Hinweis, daß die Kontrolle über
    die Entwicklung damit in die Hände des Managements übergehe. Naur macht diese Hoffnung zunichte.

    Seine Sicht ist aber auch gefährlich für die Informatiker. Sie verleitet möglicherweise zur Selbstüberschätzung (»ohne mich geht es nicht«) und zum wilden Drauflos-Hacken (»warum soll ich mich denn um eine klare Programmstruktur oder um Dokumentation bemühen, wenn das eh nicht reicht, das Programm zu verstehen«).

    Natürlich sind diese Gefahren kein Argument gegen die Plausibilität von
    Naurs Sichtweise. Die Erfahrung spricht für seine Theorie. Auch 30 Jahre Software Engineering und immer weiter verfeinerter Entwicklungsmethodologien haben nichts daran geändert, daß es bei großen Systemen oft einfacher ist, sie neu zu schreiben, als den alten Code von einem neuen Team modifizieren zu lassen. Wir sollten den Tatsachen ins Auge sehen und mit Naurs Erkenntnis leben lernen.“

    Zitat von Christian Siefkes, Jamal Abu Hasan; 1999;
    http://www.siefkes.net/textde/gedanken.pdf

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s


%d Bloggern gefällt das: