Nach 30 Jahren noch lesenswert: Philip Krafts Analyse zur Industrialisierung der Software-Entwicklung

by

Bereits 1979 veröffentlichte der amerikanische Soziologe Philip Kraft einen Aufsatz über „The Industrialization of Computer Programming: From Programming to ‚Software Production’“. Die Prognosen Krafts wurden nur teilweise bestätigt. Mit der zweiten Industrialisierungswelle in der Softwareentwicklung gewinnt seine Analyse neue Aktualität. Auf Basis neuer Technologien und in Verbindung mit der Internationalisierung der Softwareentwicklung begegnen uns heute wieder die von Kraft analysierten Managementstrategien.

In seinem Aufsatz widersprach Kraft der These, die zunehmende Computerisierung entlaste die Arbeitenden von Routinearbeiten und gebe ihnen Raum für interessante und anspruchsvolle Tätigkeiten. „Machines should work, people should think“ war seinerzeit ein Werbeslogan der IBM. Am Beispiel der Programmierarbeit zeigte Kraft, dass das Gegenteil der Fall war. Dabei bezieht er sich auf die Ergebnisse seiner 1977 veröffentlichte Studie „Programmers and Managers. The Routinization of Computer Programming in the United States“.

Software-Krise

In den 1950er Jahren galt Programmierung als hochqualifizierte, ganzheitliche Tätigkeit: Analyse, Entwurf, Programmierung, Test und Installation lagen in den Händen eines Teams, oft sogar einer einzigen Person. Nur in wenigen Großprojekten wurde schon sehr bald zwischen Systemanalyse und Programmierung differenziert. Erfahrene Programmierer/innen waren rar und damit teuer. Ihre Identifikation mit der Firma ließ zu wünschen übrig, sie galten als unsozial, eigensinnig und schlecht integrierbar. Mit anderen Worten: Das Management wusste nicht wie es die Programmierarbeit steuern und kontrollieren sollte. Mit der relativen Zunahme der Softwarekosten an den gesamten IT-Kosten wurde das zu einem ernsten Problem. Die „Software-Krise“ war geboren. Softwareengineering und Industrialisierung sollten sie überwinden.

Babbage-Prinzip

Nach dem Babbage-Prinzip sollte auch die Softwareentwicklung in komplexe und einfache Arbeiten zerlegt und unterschiedlichen Personen zugeordnet werden. Damit würden weniger hochqualifizierten Arbeitskräfte gebraucht und die Gesamtlohnkosten könnten minimiert werden. Genauso wichtig war aber auch, dass das Management so die Kontrolle über den Arbeitsprozess gewann. Die fragmentierten, einfachen Teilarbeiten mussten ja wieder kombiniert und integriert werden. Durch technologische Weiterentwicklungen wie höhere Sprachen sollte die Programmierung immer einfacher werden, um schließlich ganz auf die Programmierer/innen verzichten zu können. Dieser ewige Traum des IT-Managements wurde schon 1959 geträumt:

„Progress in all of these areas of [software] research have important implications for management control systems. In the area of programming language, developments will make it possible for programs to be written and modified more efficiently both from the standpoints of man hours and elapsed time required. It will also make it possible for less highly trained personnel to program the computer. The ultimate is to remove the programmer entirely from the process of writing operational programs. In effect, the manager would write and modify his own programs.“ (IT-Berater Bosak auf einer Konferenz der System Development Corporation)

Strukturierte Programmierung

Nach Kraft ermöglichte ab 1970 die strukturierte Programmierung die systematische Transformation von der handwerklichen Fertigung in die industrielle Produktion. Zur strukturierten Programmierung gehörten Methoden (strukturierte Analyse und strukturiertes Design), Vorgehensweisen (Top-Down, Wasserfall) und Organisationsmodelle (Chef-Programmier-Teams). Die Softwareentwicklung wurde dadurch plan- und kontrollierbar: Einige wenige hochqualifizierte Chefprogrammierer oder Systemanalytiker zerlegten das zu bauende System hierarchisch in Komponentengruppen, Module und Subroutinen. Diese wurden zur Programmierung an Programmierer/innen oder Kodierer/innen verteilt. Dabei waren Standards einzuhalten (maximale Anzahl von Instruktionen je Modul, Einschränkung von Instruktionsfolgen, Namenskonventionen bis hin zur Normierten Programmierung). Kenntnisse des Gesamtkontextes waren für die normalen Programmierer/innen nicht mehr notwendig, sie verrichteten Routinearbeiten. Sie benötigten weder fachliche, noch vertiefte technische Kenntnisse. So konnte Software arbeitsteilig und kontrolliert am (virtuellen) Fließband produziert werden.

Kraft ging davon aus, dass das Management noch an einigen Stellen experimentieren müsse, dass sich die Industrialisierung aber durchsetzen werde – wie in allen anderen Berufszweigen. Er wies aber auch daraufhin, dass Softwareentwicklung als Kopfarbeit nicht in dem Maße fragmentiert und auf einfache Verrichtungen reduziert werden könne wie etwa die Automobilproduktion. Daher seien ergänzende Managementstrategien notwendig, um die die Programmierer/innen zu Höchstleistungen zu treiben und sie vom Widerstand gegen ihre Dequalifizierung abzuhalten. Die Erzeugung von Karrierehoffnungen und die Definition eines individualisierenden Professionalismus sah er als solche Strategien an.

Software-Factories

Die vor allem in Japan zeitweilig erfolgreichen Software-Factories schienen die Analyse Krafts zu bestätigen. Oft scheiterte der Fabrikansatz jedoch am Widerstand der Entwickler/innen. Die Factories waren am ehesten bei der mehrfachen Erstellung der im Grunde immer gleichen Software für unterschiedliche (Kunden-)Umgebungen erfolgreich. Standardsoftware und Hardwareabstraktion beseitigten dieses Marktsegmen. In den 1990er Jahren wollte niemand mehr etwas von Software-Factories wissen. (siehe dazu ausführlicher „Programmierer in die Fabrik!“)

Auch die schwergewichtigen Prozessmodelle stießen an Grenzen, womöglich gerade dort, wo sie erfolgreich durchgesetzt wurden: Viele Entwickler/innen waren es leid, die notwendigerweise immer vorhandenen Defizite der Prozesse mit persönlichem Engagement aufzufangen. Die Aufnahme neuer Kundenanforderungen war mit dem Top-Down-Vorgehen nur schwer möglich. Mit agilen Vorgehensweisen wurden die erstarrten Prozesswelten aufgebrochen, auch um neue Technologien wie Objektorientierung und Internet adaptieren zu können. Von Dequalifizierung und Routinisierung der Softwareentwicklung konnte in dieser Periode nicht die Rede sein, wenn die meist stupiden Anpassungsarbeiten zum Jahrtausendwechsel mal außen vor gelassen werden.. Internethype und Jahrtausendwechsel stärkten die Marktmacht der Programmierer/innen. Das Management musste Spielräume zugestehen und gut bezahlen. Diese gegenläufigen Tendenzen erklärt uns der analytische Ansatz Krafts nicht.

Verlängerte Werkbank

Model Driven Development und Domain Specific Languages können aber auch heute wieder die Aufspaltung der Programmierarbeit unterstützen. Einige wenige Spezialisten erzeugen das Modell, viele gering qualifizierte Entwickler/innen füllen dann die generierten Methoden aus. Oder einige wenige hochqualifizierte Spezialisten bauen die domänenspezifische Sprache, ihre Anwendung ist einfach und bedarf keiner besonderer Qualifikationen. Die Internationalisierung der Softwareentwicklung nach dem Prinzip der verlängerten Werkbank kann als Anwendung des Babbage-Prinzips interpretiert werden. Gut bezahlte Analytiker und Architekten spezifizieren die Aufgaben, die dann offshore in Niedriglohnländern abgearbeitet werden. (siehe dazu ausführlicher „Deutsche Herren – indische Knechte“) Diese Form der Industrialisierung dominiert heute wohl den Software-Dienstleistungsbereich, wo hauptsächlich über die Kosten konkurriert wird. Wo über innovative Produkte oder Qualität konkurriert wird, scheinen abgewandelte Management-Strategien zum Zuge zu kommen. Methoden wie Scrum erlauben es, die Kreativität und das Engagement der Entwickler/innen abzugreifen, ohne von einzelnen Köpfen abhängig zu werden. (siehe dazu „Agile Methoden als Wegbereiter eines neuen Typs der Industrialisierung …“).

Zukunft

Philip Kraft sagte den Programmier/innen keine gute Zukunft voraus. Sie seien dem Management widerstandslos ausgeliefert, weil sie sich individualisieren ließen und sich die Gedankenwelt des Managements zu Eigen machten. Durch die Herstellung eines weltweiten Arbeitsmarktes besteht zum ersten Mal in der Geschichte der Programmierung kein Mangel an Softwareexperten. Das alleine würde eine düstere Prognose begründen. Andererseits verfällt das Vertrauen ins Management rapide und Arbeitskämpfe in der IT-Branche werden häufiger.

Literatur:

Nathan Ensmenger, William Aspray: „Software as Labor Process

Philip Kraft: The Industrialization of Computer Programming: From Programming to „Software Production“. In: Andrew Zimbalist (Ed.): Case Studies on the Labor Process. New York, 1979

Philip Kraft: Programmers and Managers. New York, 1977

Advertisements

Schlagwörter: ,

3 Antworten to “Nach 30 Jahren noch lesenswert: Philip Krafts Analyse zur Industrialisierung der Software-Entwicklung”

  1. seneca Says:

    der Link „Software as Labor Process“ hat am Ende eine Klamme – bitte entfernen !

    http://go2.wordpress.com/?id=725X1342&site=itworker.wordpress.com&url=http%3A%2F%2Fwww.sas.upenn.edu%2F~nathanen%2Ffiles%2Fensmenger2002.pdf)

  2. itworker Says:

    @seneca
    Danke für den Hinweis.

  3. //SEIBERT/MEDIA Weblog » Blog Archiv » Das Review-Meeting in Scrum: “Das haben wir geschafft!” Says:

    […] in der Software-Entwicklung ein Trend verfolgt, der sich letztlich als Irrweg herausgestellt hat: Die Software-Industrialisierung. Kurz gesagt, wurden dabei die Arbeitsschritte und Verantwortlichkeiten des einzelnen Entwicklers […]

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: