Advertisement

Zur Struktur des Feldes Programmierarbeit

  • Jörg Strübing
Chapter
  • 20 Downloads
Part of the DUV Sozialwissenschaft book series (DUVSW)

Zusammenfassung

Es gibt eine Reihe guter Gründe, gerade am Feld der Programmierarbeit die Qualität »subjektiver Leistungen« und ihre Rolle im Arbeitsprozeß zu untersuchen, einige davon wurden im Vorwort bereits angerissen. Dieses Kapitel bezweckt abgesehen davon, daß es diese Gründe präzisiert, zweierlei: Zunächst bereitet es die analytische Auseinandersetzung mit empirischen Arbeitsstilen von Softwareentwicklerinnen insofern vor, als mit der Darstellung der Strukturen des Feldes Programmierarbeit die arbeitsstofflichen, qualifikatorischen und organisatorischen Rahmenbedingungen geklärt werden, mit denen die Arbeitenden es in ihrer »Tätigkeit« zu tun haben. Dabei werden sich auch Hinweise darauf ergeben, inwiefern Programmierarbeit partiell andere Strukturen aufweist als andere Bereiche gesellschaftlicher Arbeit — ohne daß diese Studie allerdings eine vergleichende Untersuchung zum Ziel hätte. Zugleich bietet das Kapitel aber der Leserin/dem Leser eine Einführung in die Spezifika des Feldes, über das mehr gesellschaftliche Stereotype als Fakten verbreitet sind.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 20.
    Die Computerentwicklungen von Konrad Zuse, dessen Z3 Relaisrechner mitunter als erster Computer firmiert, tatsächlich aber parallel zu den amerikanischen Projekten entstand (It. Zuse 1941 fertiggestellt; vgl. Zuse 1980: 612), waren auch für die BRD entschieden weniger geschichtsmächtig, da - auch infolge des Kriegsausgangs - hiesige DV-Geschichte (zumindest hinsichtlich ihres technischen Aspekts) vor allem in der Frühzeit wesentlich aus der Adaption angelsächsischer Entwicklungen bestand.Google Scholar
  2. 21.
    Für Kraft - wie für viele andere Autoren - gilt der ENIAC-Rechner von 1946 als erster elektronischer Rechner der Welt. Brödner u.a. (1982: 42f) weisen dagegen auf eine britische Elektronenrechnerentwicklung unter der Bezeichnung »Colossus« hin, die bereits 1943 inGoogle Scholar
  3. 23.
    Mit der Rolle der Frauen in Geschichte und Gegenwart der Datenverarbeitung beschäftigt sich Hoffmann (1987).Google Scholar
  4. 24.
    Also kurz vor den ersten nicht-militärischen Nutzungen von Computern 1951 (vgl. Brödner u.a.. 1982: 46).Google Scholar
  5. 25.
    Backus ist einer der »Erfinder« der wiss. Programmiersprache »Fortran«.Google Scholar
  6. 26.
    Bereits 1958 wurde mit ALGOL die erste Programmiersprache geschaffen, die sich - in diesem Punkt vorbildhaft - von den Maschinenstrukturen löste; ihre Verbreitung blieb allerdings auf den universitären Bereich beschränkt (Eggeling 1985: 30).Google Scholar
  7. 30.
    Ich verwende die Begriffe »Softwareentwicklung» und »Programmierarbeit« bzw. »(Software) Entwicklerinnen« und »Programmiererinnen« synonym. Dies hat in den Interviews mitunter zu Beginn zu einigen Irritationen geführt, die sich jedoch als aufschlußreich erwiesen (vgl. Abschnit 4. 2. 1 ).Google Scholar
  8. 31.
    Vgl. Statistisches Bundesamt (1975).Google Scholar
  9. 32.
    Vgl. dazu auch die Kritik von Roth/Boß (1990).Google Scholar
  10. 33.
    Vgl. Bäßler u.a. (1986 u. 1987) sowie Rohlfing (1985).Google Scholar
  11. Zu den Merkmalen von Professionalisierungsprozessen siehe Beck/BraterfDaheim (1980: 811f). Zögerliche Professionalisierung drückt sich nach Ansicht von Dostal (1987: 5) auch darin aus, daß viel Beschäftigte mit DV-Schwerpunkt sich bei Befragungen immer noch eher ihren ”herkömmlichem« Berufen zuordnen. Daraus schließt Dostal, daß die tatsächliche Zahl der DV-Fachkräfte deutlich größer ist, als die im Mikrozensus erhobenen Zahlen.Google Scholar
  12. 35.
    Berufsbezeichnungen in den DV-Branchen und Tätigkeitsfeldern sind nicht geschützt oder gar monopolisiert (sieht man von der Bezeichnung »Informatikerin/Informatiker«, die ein einschlägiges Studium an einer Fachhochschule oder Technischen Universität erfordert, einmal ab).Google Scholar
  13. 36.
    Produktion« ins Sinne einer Reproduktion von aus Entwicklungsprozessen hervorgegangenen Prototypen ist für die Herstellung von Software unnötig, da identische Reproduktionen durch schlichtes Kopieren beliebig hergestellt werden können (vgl. Abschnitt 2.4). Selbstverständlich müssen auch die Millionen von Kopien von Standard-Anwendungsprogrammen »produziert« werden, doch ist dies nicht Gegenstand der Softwareerstellungsprozesse wie sie hier thematisiert werden. Es ist daher auch absolut unzulässig, Programmierarbeit in Analogien zu jedweder Form von Industriearbeit darzustellen, wie vor allem in einigen Studien der späten siebziger Jahre in den USA geschehen (Kraft 1977, Greenbaum 1979 ).Google Scholar
  14. 39.
    Neuere Zahlen liegen für die Bundesrepublik Deutschland bislang nicht vor.Google Scholar
  15. 40.
    Dabei beziehe ich mich - mangels Zahlenmaterials - auf meine unsystematischen Wahrnehmungen im Feld. Zwar gibt es eine 1984 unter weiblichen berufstätigen GI-Mitgliedern durchgeführte Erhebung, doch gewann man dort keine Vergleichszahlen, weil nicht der Anteil der Frauen, sondern nur die Gruppe selbst erhoben wurde (Brunk u.a. 1985 ).Google Scholar
  16. 41.
    Zit. n. Frankfurter Rundschau vom 17. 3. 1992.Google Scholar
  17. 44.
    Eine besonders klar verständliche Definition von »Algorithmus« bietet der Informatik-Duden: »Unter einem Algorithmus versteht man eine Verarbeitungsvorschrift, die so präzise formuliert ist, daß sie von einem mechanisch oder elektronisch arbeitenden Gerät durchgeführt werden kann. Aus der Präzision der sprachlichen Darstellung des Algorithmus muß die Abfolge der einzelnen Verarbeitungsschritte eindeutig hervorgehen. Hierbei sind Wahlmöglichkeiten zugelassen. Nur muß dann genau festliegen, wie die Auswahl einer Möglichkeit zu erfolgen hat« (1988: 25). Algorithmen unterscheiden sich zwar in ihrer Eindeutigkeit von vielen Bereichen lebensweltlicher »Regeln« (die z.B. Ausnahmen und Interpretationsspielräume zulassen), sind aber nicht auf computerisierte Strukturen beschränkt (Rezeptwissen etwa weist in vielen Fällen die gleiche Struktur auf).Google Scholar
  18. 46.
    Sprache, in der das Quellprogramm verfaßt wurde, in eine maschinennahe Assembler-Sprache, die sogenannte »Zielsprache., von wo aus sie in einem weiteren Umsetzungsgang, dem Assemblieren in die basale, binärlogische Struktur der Hardware überführt wird, den »Maschinencode«. Der Grund für dieses Verfahren liegt primär in der Laufzeiteffektivierung: Maschinen »verstehen« höhersprachige Befehle nicht, und die Vorab-Übersetzung der Befehlssequenzen ist in der Regel effizienter als eine in die Ausführung integrierte Übersetzung. Bei Programmen, die parallel ablaufende Funktionen enthalten, muß im Prozeß des Compilierens zugleich die einlinige Sequenzialität, in der der Programmcode niedergeschrieben wird, aufgelöst werden.Google Scholar
  19. 47.
    Es existieren derzeit ca. 100 Programmiersprachen, von denen rund 20 als verbreitet anzusehen sind (vgl. Informatik-Duden 1988: 460ff.).Google Scholar
  20. 48.
    Rein sequentielle. »deterministische. Stapelprogramme sind meist weniger problematisch als interaktive Online-Systeme, die auf einen »nicht-deterministischen. Benutzer abgestimmt sind, der unvorhersehbar agieren kann.Google Scholar
  21. 49.
    Dafür hat sich der Begriff der «evolutionären Systementwicklung« etabliert.Google Scholar
  22. 50.
    Es ist allerdings anzunehmen, daß die Geschwindigkeit des Wissensumschlages nicht für alle Zeiten konstant bleibt, sondern sich auch hier, wie in anderen Bereichen gesellschaftlicher Produktion eine Art von Konsolidierung ergeben wird.Google Scholar
  23. 51.
    Besonders deutlich wird dieser Umstand im Vergleich mit den von Ekardt u.a. analysierten Tätigkeiten der Baubranche, die mit einem hohen Maß an Technischen Normen, vielfach auf der Grundlage baurechtlicher Regelungen, umgehen müssen (Ekardt u.a. 1988: 21). Die geringe Regelungsdichte in der Softwarebranche ist aber möglicherweise ein eher vorübergehendes Phänomen: 1m Bereich der Datenfernübertragung etwa läßt sich breits eine große Zahl absolut verbindlicher »Protokolle« ausmachen, also Normierungen von Kommunikationsschnittstellen. Die Bemühungen um verstärkte Wiederverwendbarkeit von Software (vgl. dazu etwa Barthel 1990) drängen auf eine Standardisierung der Softwaregestaltung, wie sie z.B. mit dem SAA-Standard von IBM für Bedienoberflächen bereits Gestalt anzunehmen beginnt - auch wenn zur Zeit noch nicht absehbar ist, welche Standards sich letztendlich durchsetzen werden.Google Scholar
  24. 52.
    Programmiersprachen sind aber - das ist wichtig - mehr als nur Vergegenständlichungen von Arbeitsstofflichkeit: In ihnen sind z.T. auch organisationspolitische Ziele implementiert (z.B. bestimmte Strukturierung.sziele: vgl. Eggeling 1985).Google Scholar
  25. 53.
    Darauf verweisen auch Frese u.a. (1991: 340).Google Scholar
  26. 57.
    In ihrer Darstellung arbeitslogischer Basisprobleme lassen Ekardt u.a. das »Kontingenzproblem« auf die Diskussion des »Aushandlungsproblems« folgen (vgl. Kap.1). Ich halte es allerdings für sinnvoll, letzteres für einen Moment zurückzustellen, da die spezifischen Konnotationen des »Aushandlungsprohlems« in der Programmierarbeit sehr stark auf Kontingenzphänomene bezogen werden müssen.Google Scholar
  27. 63.
    Selbstverständlich kann fehlerbehaftete Software große materielle Schäden bewirken (und tut dies oft genug), wenn sie zum Einsatz kommt. Mein Argument aber ist grundsätzlicherer Natur: Das diffizile, in einem aufwendigen Prozeß des Entwerfens und Codierens hervorgebrachte technische Artefakt Programm kann, auch wenn es bereits realisiert ist, jederzeit modifiziert werden, ohne als Ganzes neu produziert werden zu müssen. Hier liegt eine kategoriale Differenz gegenüber nicht-virtuellen Artefakten.Google Scholar
  28. 64.
    Vgl. dazu WeltziLullies (1984) und feldspezifisch Weltz/Ortmann (1992).Google Scholar
  29. 65.
    Dabei ist zu beachten, daß die Aufgabenverteilung zugleich auch Einfluß auf die Produktgestaltung hat, weil a) die Form der Modularisierung in einem Interdependenzverhältnis zur gegenstandsbezogenen Arbeitsteilung steht und b) konstitutive Leistungen personenabhängig sind: A wird das Problem anders lösen als B.Google Scholar
  30. 66.
    Rautenberg (1991: 105) unterscheidet noch differenzierter »Anwender« (»alle Personen (.), die über die Anforderungen an das gesamte Arbeitssystem Aussagen treffen können«) von »Benutzern« (»Personen (.), welche die Ergebnisse, welche mittels des Softwaresystems erstellt werden, (...) benötigen«) sowie von «End-Benutzern» (»Personen (.), von denen dasGoogle Scholar
  31. 71.
    Diesen Aspekt habe ich bereits in Strnbing (1987) dargestellt.Google Scholar
  32. Diese Studie versteht sich nicht als repräsentativ, sondern betont vielmehr in der Strukturierung ihres Samples vor allem strategisch bedeutsame Projekte der jeweiligen Firmen (Weltz/Ortmann 1992: 55 ). Dies hat zur Folge, daß Kleinprojekte, die lediglich von ein bis zwei Entwicklerinnen bearbeitet werden, stark unterrepräsentiert sind. Dies relativiert den Geltungsbereich vor allem der Aussagen über Arbeitsteilungsmodi und Leitungsorgansiation.Google Scholar
  33. 76.
    Befragt wurden (sowohl mit Leitfadeninterviews als auch mit standardisiertem Fragebogen) 200 Mitarbeiterinnen aus 29 Projekten in der I3RD und der Schweiz. Im Sample vertreten sind alle Bereiche kommerzieller Softwareentwicklung, jedoch keine militärischen und keine wissenschaftlichen Projekte. Projekte zur Entwicklung von Prozeßsteuerungen, wie sie für das produzierende Gewerbe typisch sind, sind mit nur einem Projekt deutlich unterrepräsentiert.Google Scholar
  34. 77.
    Diese Art der Projektdurchführung. das auf einer Art »Bodyleasing«-Verfahren basiert, bei dem Softwarefirmen Entwicklungsaufträge direkt beim Kunden ausführen und im Grunde eher die Dienstleistung als das Produkt verkaufen, ist sicher eine extreme Variante, aber in der Branche auch nicht unüblich.Google Scholar
  35. 78.
    Man darf nicht unterschätzen, daß Zeitkalkulationen auch dazu dienen, MitarbeiterInnen unter Zeitdruck zu setzen und sie so zu »motivieren«. Bei offen zyklischer Vorgehensweise, die keine handhabbaren Zeitkalkulationen zuläßt, erscheint dies deutlich schwieriger.Google Scholar
  36. 80.
    Zu methodischen Fragen siehe den diesbezüglichen Anhang.Google Scholar

Copyright information

© Springer Fachmedien Wiesbaden 1993

Authors and Affiliations

  • Jörg Strübing

There are no affiliations available

Personalised recommendations