Advertisement

Subjektive Leistungen und ihre Bedeutung in der Programmierarbeit

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

Zusammenfassung

Wie stellen sich — im Überblick betrachtet — »subjektive Leistungen« in der Programmierarbeit dar, und inwiefern sind diese für arbeitspolitische Fragen von Belang? Dies sind die Kernfragen, die das abschließende Kapitel strukturieren sollen. Dazu greift ein erster Abschnitt (5.1) zunächst die Ergebnisse der beiden vorangegangenen Kapitel noch einmal auf, um sie zu einer typologischen Skizze der Praxis von SoftwareentwicklerInnen zuzuspitzen. Daran anschließend sollen dem Ansatz der »subjektiven Leistungen« andere Beschreibungsversuche und Erklärungsmodelle von Programmierarbeit vergleichend gegenübergestellt werden.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 146.
    Vgl. Johnson/Kaplan (1979) und Johnson (1981).Google Scholar
  2. 147.
    Das Schaubild darf keinesfalls als »Ergebnis« der Untersuchung mißverstanden werden. Es stellt vielmehr eine Orientierungshilfe in den hier und im vierten Kapitel formulierten Befunden dar.Google Scholar
  3. 148.
    Das bedeutet in diesem Beispiel umgekehrt: Wenn eine Organisation auf technisch gut unterstützte, systematisierte und lückenlos dokumentierte Tests - etwa aus Gründen der Qualitätskontrolle - Wert legt, müßte bereits im Vorfeld eine andere Sprache gewählt werden. Dies mag aber mit anderen Organisationszielen oder technischen Restriktionen kollidieren, z.B. wenn für Echtzeitverarbeitung hohe Geschwindigkeiten der Programme erforderlich sind.Google Scholar
  4. 149.
    Es können auch in größeren Firmen andere Kostenstellen als Auftraggeber auftreten.Google Scholar
  5. 154.
    Womit nicht ausgeschlossen sein soll, daß sie Organisationstatbestände auch unangemessen wahrnehmen und in ihrem Handeln Organisationsziele oft unbewußt, durchaus aber auch intentional verfehlen können. Dies ist aber - wie der Fortbestand der Arbeitsorganisation belegt - nicht die Regel.Google Scholar
  6. 155.
    Es gibt einen guten Grund, hier ausdrücklich von »technisch-fachlichem« und nicht etwa nur von »technischem« Gegenstand zu sprechen: Es ist nicht die Technik, etwa in Gestalt von im eigenen Verfügungsbereich liegenden Computern, auf die sich die beschriebene Neigung bezieht, sondern in der Tat die fachliche Aufgabe. etwas - in einer spezifischen Weise - einer technischen Lösung zuzuführen. Auf diesen gemeinsamen Nenner lassen sich nicht nur die Außerungen der eher zum »hacken« tendierenden Entwicklerinnen, sondern auch die der den Geräten selbst eher distanziert gegenüberstehenden Befragten bringen.Google Scholar
  7. 156.
    Fragen zur Weiterbildung gehörten mit zum Kanon der Fragen in den Leitfadeninterviews. Eine systematische Analyse dieses Aspektes im Material steht indes noch aus, daher geben diese Anmerkungen nur einen ersten, allerdings verifizierbaren Eindruck wieder.Google Scholar
  8. 157.
    Zwar gibt es eine Reihe von Unterschieden zwischen US-amerikanischen und bundesdeutschen Softwareprojekten etwa hinsichtlich der Personalrekrutierung und der Arbeitsteilung, dennoch aber sind die hier präsentierten Ergebnisse allgemein genug, um auch für deutsche Softwareentwicklung instruktiv zu sein.Google Scholar
  9. 158.
    Die Begründung für diese Methodenwahl ist allerdings wenig zufriedenstellend: Man erhoffte sich von Feldforschungsmethoden schnellere Ergebnisse (1988: 12681. Das tatsächliche Potential eines solchen methodischen Rahmens - Einsicht in Kontextbezüge, Generierung neuer Indikatoren und Kausalbezüge - blieb so unausgeschöpft.Google Scholar
  10. 161.
    «Top-Down-Entwurf« ist die Methode, ein Program vom Allgemeinen zum Speziellen hin zu entwerfen, also zunächst mit einem groben Modell des Verhältnisses wesentlicher Systemelemente zu beginnen, dabei diese Elemente zu definieren und gegeneinander abzugrenzen (Schnittstellen definieren) und dann Schritt für Schritt den Entwurf der einzelnen Komponenten zu detaillieren («stepwise refinement«). Vgl. dazu auch Informatik-Duden (1988: 550).Google Scholar
  11. 162.
    Der Unterschied liegt allerdings darin, daß sich <Durchmischung< auf die Integration verschiedener Phasen des gesamten Entwicklungsprozesses ineinander bezieht, während Guindon ausschließlich die Entwurfsphase untersucht und die dort aufweisharen kognitiven Strategien herausarbeitet.Google Scholar
  12. 163.
    Mit dem Topos der Erfahrungsgebundenheit differierender Arbeitsweisen in der Softwareentwicklung hat sich eine große Zahl von Studien befaßt (vgl. z.B.: Perkins/Martin 1986; Mynatt u.a. 1991).Google Scholar
  13. 164.
    Es soll nicht unerwähnt bleiben, daß Visser (1987) in einer anderen empirischen Studie, die erfahrene Programmierer in teilnehmenden Beobachtungen untersucht, zu ähnlichen Ergebnissen wie Guindon kommt, dabei allerdings den Vorzug hat, ihre Resultate in Prozessen realer Erwerbsarbeit und nicht - wie Guindon und viele andere Forschungsgruppen - in experimentellen settings zu gewinnen.Google Scholar
  14. 165.
    Wie die hohe Motivation von Entwicklerinnen in die Vorgaben integriert wird, konnte ich an anderer Stelle (Strübing 1987: 199) am Beispiel der “Leitkalkulation zeigen: Dort wurden die Arbeitenden in die vorab zu leistende Zeitplanung miteinbezogen, ohne allerdings ihren Wunschzeitplan durchsetzen zu können: denn dieser wäre von Vorgesetzten als unrealistisch zurückgewiesen worden. Die Beteiligung an der Planung führt aber dazu, daß Entwicklerinnen sich mit den Planungskompromissen im Sinn einer Selbstverpflichtung zu identifizieren beginnen und deren Unzulänglichkeiten durch persönliche Mehrleistungen zu kompensieren versuchen.Google Scholar
  15. 168.
    Derartiges Lernen an der Praxis kann auch der mit Fragen der Softwareentwicklung befaßten Sozialwissenschaft nicht schaden: Es ist schon interessant zu sehen, daß etwa Friedrich (1988) der Programmierarbeit noch den gleichen Entwicklungspfad prognostiziert, wie ihn vormals die Industriearbeit beschritten hat. Er schreibt: »Etliche Anzeichen sprechen dafür, daß der Prozeß der Software-Produktion durchaus Ahnlichkeiten mit dem Prozeß der materiellen Produktion aufweist. (…) Jedenfalls legen die genannten Analogien die These nahe, daß die Maschinisierung der Software-Produktion von heute und morgen ähnliche Auswirkungen auf die Software-Entwickler haben wird, wie dies bei der Maschinisierung der materiellen Produktion bezüglich der Industriearbeiter von gestern und heute der Fall ist« (1988: 680f.). Diese Aussagen sind explizit orientiert an den verlautbarten Konzepten des Software Engineering, übersehen aber den Unterschied zwischen Plan und Wirklichkeit.Google Scholar
  16. 169.
    Programmiererinnen in Testabteilungen ist es in der Regel untersagt selbst Anderungen am Produkt vorzunehmen, sie müssen diese - oft stark formalisiert - an die Autorinnen zurückmelden. um die Konsistenz des Produktes nicht zu gefährden.Google Scholar
  17. 170.
    Für ein recht aktuelles Beispiel: Sösemann (1989).Google Scholar
  18. 171.
    Was für den Laien - zugegebenermaßen - schon imponierend genug ist.Google Scholar
  19. 172.
    Zur Kritik mangelnder sozialkommunikativer Orientierung in Ausbildung und Praxis der Softwareentwicklung vgl. auch die empirisch fundierte, detaillierte Kritik von Pasch (1991). Dort wird dem herrschenden Paradigma technisch orientierter Informatik ein Leitbild kooperativer, dialogisch orientierter Softwareentwicklung gegenübergestellt.Google Scholar
  20. 174.
    Täten sie dies, so käme jene Perspektive in ihr Blickfeld. die die PAQ als «inhaltliche Politisierung« bezeichnen und von einer bloß «formalen« unterscheiden: Bei ersterer handelt es sich um eine Art der Politisierung «in der das Wozu und Wie der Produktion in Frage gestellt wird, und alternative >Wozus< und >Wies< entwickelt werden« (PAQ 1987: 150).Google Scholar
  21. 176.
    Selbstverständlich gehen » Anfordemmngen < und arbeitsstoffliche Erfordernisse nicht ineinander auf, erstere Kategorie ist vielmehr umfassender und anders zugeschnitten (vgl. dazu Kapitel zwei).Google Scholar
  22. 177.
    Es gibt eine Reihe empirischer Hinweise und gute theoretische Gründe, hinsichtlich der Arbeitstypik Forschungstätigkeit und Softwareentwicklung recht nah beieinander anzusiedeln. Ich habe auf eine diesbezügliche Argumentation hier verzichtet, weil meinem Verständnis nach für seriöse diesbezügliche Aussagen eine vergleichende Analyse erforderlich gewesen wäre, die hier jedoch nicht mein Anliegen ist.Google Scholar

Copyright information

© Springer Fachmedien Wiesbaden 1993

Authors and Affiliations

  • Jörg Strübing

There are no affiliations available

Personalised recommendations