2.3 Von der Tragödie zur Farce

Oft scheiterte die Umsetzung der Fabrikkonzepte am Widerstand der Entwickler/innen. Wo der Widerstand gering war, produzierten einige Fabriken über viele Jahre Software. Aber auch diesen blieb langfristig der Erfolg verwehrt, ihr Marktsegment brach weg, Standardsoftware setzte sich durch. Nach der Analyse des historischen Scheiterns des Fabrikansatzes stellt sich die Frage, ob heute Bedingungen gelten, die mehr Erfolg versprechen.

Widerstand der Entwickler/innen

Finn Borum analysierte 1987 das Scheitern des Fabrikansatzes in Dänemark.

„By imposing standardization and supervision of the specialists‘ practice at least two objectives were pursued. One was to reduce costs, another two reduce dependency on the individual specialist. By making their working methods conform to certain norms, and their products to certain standards, the expropriation of craft knowledge, and the replaceability of the individual specialist were obtained. …
However, these efforts that essentially deskill the IT-specialists were resisted by the specialists in several ways. One was to leave the organizations, if control measures that implied a formalization beyond the specialists‘ threshold of tolerance were imposed. … The second type of resistance was to bypass the rules and regulations imposed. This is a common story from the installations with well-developed methods and standards: that they do exist, but are only utilized to a limited extent. …
Thirdly, rule enforcement is complicated by the fact that the managers and supervisors in nearly all cases are IT-specialists themselves. Thus they know the problems connected with strict rule adherence, and perhaps share the craft values of the specialists they are supposed to supervise.“ (zitiert nach Cusuman, 1991)

Dass solcher Widerstand kein rein dänisches Phänomen war, sondern genauso in den USA, in Japan und andernorts zu finden war, bestätigt Cusumano 1991, damals noch Anhänger des Fabrikkonzepts.

Auch ich selbst durfte in den achtziger Jahren die Einführung eines CASE-Tools scheitern sehen. Das Tool generierte aus formalisiertem Pseudocode ein Programmskelett. Dieses sollte in einem zweiten Schritt mit Cobol-Statements angereichert werden. Eine Gruppe von qualifizierteren Entwickler/innen sollte den Pseudocode schreiben, eine andere den einfachen Cobol-Code ergänzen. Der Einsatz des Tools wurde als Firmenstandard festgelegt, alle internen und externen Programmierer/innen wurden geschult. Erfahrene Projektleiter/innen hatten ähnliche Bestrebungen schon einmal erlebt und spielten deshalb auf Zeit. Wo das nicht gelang, nutzten die Programmierer/innen das Tool, um genau einen Paragraphen, sozusagen die Main-Methode, zu generieren. Alles andere wurde programmiert wie gehabt. Nach einem Jahr verschwand das CASE-Tool wieder in der Versenkung. Einige übereifrige Projektleiter hatten Erfahrungen gesammelt.

Standard- statt Fabriksoftware

Die differenziert denkenden Fürsprecher der Software Factory beanspruchten keineswegs die Allgemeingültigkeit für ihren Ansatzes. Sie sahen auch Bereiche, in denen hoch qualifizierte Entwicklerteams mit jeweils eigenen Vorgehensweisen erfolgreicher sein würden: Das war zum einen innovative Software, die individuell auf einen einzigen Kunden zugeschnitten war. Zum anderen war das Software, die überhaupt keine speziellen Kundenbedürfnisse zu berücksichtigen hatte, z.B. PC-Programme zur Tabellenkalkulation. Zwischen diesen beiden Polen wurde die Art von Software gesehen, die nicht wirklich neu war, die nur um spezifische Kunden-wünsche erweitert wurde oder die an spezifische Hardware- und Software-umgebungen angepasst wurde.

Standardanwendungen existierten Ende der sechziger Jahre so gut wie gar nicht. Anwendungen wurden für jeden Kunden und für jede Hardware / jedes Betriebs-system neu geschrieben. In den achtziger Jah-ren änderte sich das. Firmen wie SAP gelang es Standardpakete zu entwickeln und zu verkaufen, die dann beim Kunden angepasst wurden. Solche Anpassungen konnten und können noch heute sehr umfangreich sein, sind aber eben nur auf diesen einen Kunden zugeschnitten. Software war von der Hardwarebeigabe zu einem eigenständigen Produkt geworden, zu dem gegebenenfalls die passende Hardware beschafft wurde. Damit war genau der Bereich irrelevant geworden, in dem Software Factories optimal passen sollten.

Der Erfolg der Standardsoftware bestätigt die Fundamentalkritik, der Fabrikansatz erwies sich als historische Sackgasse.

Erfolgsaussichten heute

In den letzten zehn bis fünfzehn Jahren haben sich neue Programmiersprachen und Technologien sowie neue Paradigmen und Methoden durchgesetzt. Mit einer industriellen Produktion haben diese aber wenig gemeinsam.

Mit Visual Studio und Eclipse existieren inzwischen mächtige, integrierte Toolsets. Nach wie vor decken sie noch nicht den gesamte Software-Lebenszyklus ab, auch in der Unterstützung der unterschiedlichen Plattformen bleiben Wünsche offen. Für die Wiederverwendung stehen Komponenten-Technologien wie Enterprise Java Beans (EJBs) zur Verfügung. Auf der technischen Ebene hat sich durchaus einiges getan.

Prozessmodelle erlebten eine Blütezeit. Schwergewichtige Prozessmodelle wie das V-Modell 97 wurden soweit ausgearbeitet, dass Projekte unter ihrem Gewicht zusammenzubrechen drohten. Die Reaktion kam in Form von leichgewichtigen Prozessen. Im Manifest für agile Softwareentwicklung wurde wieder der Mensch in den Mittelpunkt gestellt. Inzwischen kann man auf einen reichhaltigen Fundus von Prozessmodellen in jeder Gewichtsklasse zurück-greifen. Auch Kennzahlen gibt es zuhauf, ein Standard zur Messung des Projekt-fortschritts ist jedoch nicht in Sicht. Die projektübergreifende Wiederverwendung fachlicher Komponenten hat nach wie vor Seltenheitswert.

Standardsoftware ist erfolgreicher denn je, sie hat sich durchgesetzt. Auch der Bedarf von Anpassungen an spezifische Hardwareplattformen verschwindet. Mit der Durchsetzung von Java und dessen virtueller Maschine wird eine immer stärkere Plattform-Unabhängigkeit erreicht. Das klassische Markt-Segment der Software Factories existiert definitiv nicht mehr.

Beim Verständnis der Softwareentwicklung scheiden sich die Geister. Eher fachlich orientierte Experten vergleichen die Softwareentwicklung mit der Produktentwicklung, interpretieren sie als zielgerichtetes kooperatives Spiel oder sehen Analogien zu Expeditionen. Theoretisch ist man da durchaus ein ganzes Stück weiter, die Fabrikanalogie passt weniger denn je. Management und Berater dagegen beharren, oft gegen besseres Wissen, auf der Fabrik als Leitbild.

Technische Weiterentwicklungen, Prozessvielfalt, mangelnde fachliche Wiederverwendung, Dominanz von Standardsoftware, weitere Hardware-Abstraktion, mangelndes Verständnis der Softwareentwicklung beim Management – all das spricht nicht für eine Neuauflage des Fabrikansatzes, die Tragödie wird zur Farce.

weiter

Eine Antwort to “2.3 Von der Tragödie zur Farce”

  1. karl Says:

    Für das Scheitern der ersten Generation der Software-Faktories ist sicherlich auch der Innovationsschub in den 90er Jahren verantwortlich, Objektorientierung und Internettechnologien setzten sich durch. Zu prüfen wäre die These, dass sich historisch innovationsorientierte Phasen und prozessorientierten Phasen abwechseln. Innovative Firmen sind weniger industrialisiert, prozessorientierte weniger innovativ. Mit einem Phasenwechsel müßten demnach auch jeweils andere Firmen dominieren.

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: