Notizen zu einer Sozialgeschichte der Programmierung (I)

Protokoll: Kathrin Passig

Also, ich fing an, über dein Buch nachzudenken. Ich wollte ja ursprünglich eine Rezension schreiben. Und dann fing ich an, zu recherchieren und dachte: Was ist überhaupt der theoretische Rahmen, den ich bräuchte, um über dieses Buch schreiben zu können? Dann fiel mir auf, dass es da eine Geschichte des Computers gibt, eine History of Computing, die sich sehr stark auf die Computer, also auf die Hardware, auf die Technik konzentriert, in der aber die Programmierer, also diejenigen, die diese Maschinen programmieren, interessanterweise gar nicht vorkommen.

Des weiteren gibt es eine Geschichte der Programmiersprachen. Die ist relativ elaboriert, da kann man schon einiges zu lesen. Aber in der Geschichte der Programmiersprachen wird überhaupt nicht darüber reflektiert, was denn mit diesen Programmiersprachen gebaut werden sollte, welche Systeme damit geschaffen wurden. Und ich fragte mich daraufhin: Was ist denn eigentlich ein Programmierer? Was tun eigentlich die Programmierer? Wenn man sich mal anschaut, wie groß die Branche mittlerweile ist, wie viele Programmierer es gibt, dann gibt es sehr viele: 40 Millionen Programmierer weltweit, wird geschätzt. Also Leute, die ihr Leben damit finanzieren, dass sie Programme schreiben. In der Branche arbeiten mittlerweile mehr Menschen als in allen anderen Ingenieurdisziplinen – einschließlich Architekten – zusammen.

Was machen eigentlich diese Programmierer den ganzen Tag? Die meisten Programmierer arbeiten ja eigentlich nicht direkt mit dem Computer. Der Computer, der in dieser History of Computing immer so herausgestellt wird, ist eigentlich nur ein Werkzeug, mit dem man andere Werkzeuge herstellt. Die meisten Programmierer sind auch keine Compilerhersteller. Die meisten Programmierer wissen auch gar nicht so genau, was da im Inneren dieses Computers abläuft. Wichtig ist einfach nur, dass das Ding programmierbar ist. Dazu ist es eigentlich auch egal, was für eine Prozessorarchitektur dahinter steckt oder wie das alles genau funktioniert. Hauptsache, ich kann das Ding programmieren.

Des weiteren sind die meisten Programmierer gar nicht so sehr damit beschäftigt, neue Software zu entwickeln. Je nachdem, wo man da hinschaut, liegen die Zahlen so zwischen 50 und 70 Prozent der Arbeitszeit: Das ist die Zeit, in der Programmierer den bestehenden Code warten. Und auch hier ist interessant, dass “bestehenden Code warten” nicht bedeutet, dass man Bugs fixt, also Fehler, die im Programm drin sind, rausnimmt. Nein, man passt die Programme an neue Umstände an, an neue gesetzliche Vorgaben für Unternehmen zum Beispiel. Oder an neue Geschäftsprozesse, die sich eben gewandelt haben und die angepasst werden müssen.

Interessant ist zum Beispiel auch die Tatsache, dass 90 Prozent aller Finanztransaktionen, die rund um den Globus getätigt werden, nach wie vor in Cobol-Code absolviert werden. Die Softwareindustrie, die sich immer so als bleeding-edge, als ganz vorne und als fast-moving darstellt, ist zu einem ganz großen Teil sehr konservativ, indem Strukturen, die irgendwann mal geschaffen wurden, immer weiter fortgeschrieben werden müssen. Und zwar gerade dort – das kann ich auch aus der eigenen Erfahrung sagen – gerade dort, wo man High-Tech am meisten erwarten würde, Luftfahrtbranche, Flugzeughersteller, Raumfahrtindustrie, Atomkraftindustrie. Wenn du irgendwo Maschinen aus den siebziger Jahren sehen willst … wenn du noch alten Code sehen willst, dann musst du genau da hingehen.

Sodass sich mir die Frage aufdrängte: Was tun Programmierer eigentlich? Also, die Everyday-Programmierer, was tun die und wo haben sie eigentlich ihren Platz in den Geschichten, die man so lesen kann: In der Geschichte der Programmierung, in der Geschichte des Computers. Auch die Nutzer, die interessanterweise in diesen Geschichten auch nicht auftauchen. Die Nutzer interagieren ja nicht mit dem Computer an sich, die Nutzer interagieren mit dem Mail-Programm oder mit dem Browser oder mit dem Egoshooter, also mit den Welten, die Programmierer überhaupt erst hergestellt haben. Und auch darüber kann man relativ wenig lesen, wie denn eigentlich das Verhältnis zwischen Programmierern und ihren Usern ist.

Wenn man sich dann diese Geschichten anschaut, vom geschichtswissenschaftlichen, geschichtstheoretischen Standpunkt, dann ist es klar, warum so gerne die Geschichte des Computers erzählt wird. Man hat dort ein in sich stimmiges Narrativ: die Computerindustrie, die sich immer weiterentwickelt, die Rechner, die immer schneller werden, Moore’s Gesetz. Und anhand dessen kann man eine Erfolgsgeschichte schreiben. Das, was die Programmierer machen, ist so unklar, so undeutlich, es liegt so zwischen allen Instanzen. Programmierer scheinen die zu sein, die die technische Welt und die soziale Welt miteinander in Kontakt bringen. Das ist eigentlich das, was Programmierer wirklich tun. Das ist das, was interessanterweise Programmierer von Anfang an tun.

Sodass ich mich gefragt habe: Sollte man nicht mal darüber nachdenken – und ich habe jetzt noch nicht viele Antworten, sondern ich habe erst mal viele Fragen – sollte man nicht darüber nachdenken, ob man nicht sowas wie eine Sozialgeschichte der Programmierung mal wenigstens skizzieren müsste? Wie könnte so was aussehen?

Das nächste, was mir ins Auge fiel, ist, dass bis in die späten sechziger Jahre Programmierung nicht hauptsächlich, aber auch durchaus ein Frauenberuf war. Die allerersten Programmiererinnen sind die so genannten ENIAC Girls, das sind Frauen, die bis dahin als menschliche Computer gedient hatten. Denn es gibt ja auch eine Geschichte des Computing vor dem eigentlichen Computing – so seit dem ersten Weltkrieg –, wo Frauen an Tischrechenmaschinen in strikter Arbeitsteilung Personalabrechnungswesen gemacht haben oder eben auch für die Wissenschaft irgendwelche Trajektorien von irgendwelchen Planeten berechnet haben und so weiter. Das hielt sich ja noch lange Zeit. Das hielt sich bis in die sechziger Jahre und dann geht das sehr plötzlich stark zurück, sodass wir dann schon Ende der siebziger Jahre kaum noch zehn Prozent Frauen in IT-Berufen oder Programmier-Berufen haben, mit nach wie vor sinkender Tendenz. Heute sind es noch ungefähr sieben Prozent. Wie ist denn das eigentlich zustande gekommen?

Wenn man dann weitergräbt, findet man in den späten sechziger Jahren erst mal zwei Konferenzen, die in der Literatur immer wieder genannt werden. Es sind zwei Konferenzen, die die NATO organisiert hat. Die eine hat 1968 in Garching, also hier in Deutschland stattgefunden und die andere 1969 in Wien, glaube ich, wo dann zum ersten Mal der Begriff ”Software Engineering” geprägt wurde und auch konzeptionalisiert wurde. Wo ganz offiziell – wenn man die Dokumentation zu diesen Konferenzen durchliest – beschrieben wurde, dass man offensichtlich in einer Softwarekrise steckte. So nahm man das wahr. Dass die Programmierer da irgendwie ihre schwarze Kunst vollführen und keiner so richtig weiß, was sie eigentlich so genau tun. Dass sie schlecht managebar sind, dass die Projekte alle hinter dem Schedule sind, dass sie alle über dem Budget sind.

Und das ist ja wohl auch richtig, dass es große Risiken in der Softwareentwicklung gibt. Da ist, glaube ich, kurz vorher eine Rakete abgestürzt, wegen irgendeinem Semikolon, das gefehlt hatte. Dass es kein ordentliches Qualitätsmanagement gibt, und da denkt man sich eben: Na gut, dann müssen wir daraus eben eine Wissenschaft machen, eine Ingenieurwissenschaft. Das beginnt dann erst Anfang der siebziger Jahre. Das kann man in der Managementliteratur der damaligen Zeit nachlesen, wie da versucht wird, Programmierer unter institutionelle und Unternehmenskontrolle zu bringen, indem man zum Beispiel Prozessmodelle einführt.

1971 ist dann zum ersten Mal direkt im Anschluss an diese Konferenzen das Wasserfallmodell beschrieben worden, wo man versucht hat, die Tätigkeit des Softwareentwickelns zu organisieren wie am Fließband. Durch strikte Arbeitsteilung, durch strikte Trennung von Hierarchien oder überhaupt wieder Errichtung von Hierarchien. Denn vorher hatten Programmierer immer die Tendenz, ständig zwischen den Hierarchien hin und her zu laufen. Weil sie keine reinen Techniker waren, sondern weil sie eben so zwischen Unternehmenszielen, ökonomischen Zwängen, Sozialstrukturen in Unternehmen und technischem Artefakt standen, hat man versucht, sie, ja, sie zu taylorisieren letzten Endes. Damals taucht auch der Begriff der Software Factories auf, also Software so herzustellen, wie zur selben Zeit auch versucht wurde, Konsumgüter herzustellen. Einfach alles in Arbeitsschritte aufteilen, Überwachungen, Qualitätskontrolle und dann am Schluss irgendwie verpacken und verkaufen. Und zu diesem Zeitpunkt – das ist jetzt eben auch das Interessante, und das ist, glaube ich, jetzt dann wirklich neu – zu diesem Zeitpunkt wird dann auch versucht, die Informatik zu einer Wissenschaft zu machen. Oder die Informatik als Wissenschaft überhaupt erst zu erfinden.

Zu diesem Zeitpunkt, so um 1968, 69, 70, wandeln sich dann auch ganz stark die Metaphern. Wo früher immer von Kunst geredet wurde und von Inspiration, Kreativität, auch Pflege, Pflege nämlich von alten Programmen – also sozusagen die karitative und kreative Tätigkeit bislang immer herausgestellt wurde und das Ganze in Metaphern beschrieben wurde, die aus der Ästhetik stammen. Das wandelt sich jetzt stark und es kommen plötzlich Metaphern hoch, die aus der Physik stammen und speziell auch aus der Astrophysik. Dijkstra, der eine zentrale Rolle spielt, in der Wissenschaft und in der Informatik, sagt dann, die Informatik hätte mit Computern ungefähr genauso viel zu tun wie die Astronomie mit Teleskopen. Denn ein Stern ist nicht der Lichtpunkt, den man durch ein Teleskop sieht, sondern ein Stern ist eine Summe von Formeln, die irgendwas mit Gravitation zu tun haben und Kernverschmelzungsprozessen und so, letzten Endes ist das eine Summe von Gleichungen.

Genau zu dem Zeitpunkt kommt dann auch Donald Knuth zum Beispiel, 1968 mit seinem The Art of Computer Programming. Da ging es eigentlich darum, dass man für die Informationen einen Bereich erschließt, der dann tatsächlich auch nur der Informatik selbst gehört. Das sind eben die Algorithmen, die Algorithmen sind dann sozusagen absolute Entitäten. Und eben nicht irgendwie lokale Problemlösungen, wie man eben Informatik bis dahin betrieben hatte, sondern irgendwas davon Abgehobenes, was Abstraktes, das man dann auch abstrakt betreiben kann.

Bis dahin war auch die Ausbildung von Informatikern so, dass man das an den jeweiligen Fakultäten so nebenher mitgemacht hat. Die Physiker haben ihre Fortran-Kurse angeboten, und da haben die Physiker halt so nebenher auch noch so ein bisschen programmiert. Die Biologen haben auch ihre Fortran-Kurse angeboten und haben auch so nebenher ein bisschen programmiert.

Das wäre dann schon wieder die nächste Frage: Genau zu dem Zeitpunkt wird auch von denselben Leuten, die diese NATO-Konferenzen organisiert haben, eine neue Programmiersprache ins Spiel gebracht. Das ist Ada. Also streng strukturiertes Programmieren. Und meine Frage wäre: Inwieweit muss man nicht auch die Geschichte der Programmiersprachen im Hinblick auf die politischen und ökonomischen – politökonomischen Zwänge und Interessen und Agenden sehen, die zu jener Zeit geherrscht haben. Denn, wenn man sich anschaut, wie da versucht wurde, Ada den Unternehmen, den Behörden – Ada ist bis heute ganz stark im Behördenbereich – schmackhaft zu machen, dann geht es genau darum, dass man diese schwarze Kunst der Programmierer endlich mal ordentlich systematisieren, in verschiedene Arbeitsschritte aufteilen, dadurch eben auch kontrollieren und so die Softwareentwicklung industrialisieren kann.

Das Interessante ist aber nun, dass das nie so richtig geklappt hat. Dass es auch von Entwicklerseite immer wieder Widerstand dagegen gab. Und diesen Kampf haben wir eigentlich seitdem, also mindestens seit Anfang der siebziger Jahre bis heute, und man kann lange darüber reden, wo denn da die heutigen Beispiele sind – dass die Entwickler, Programmierer immer wieder versuchen, herauszustellen, dass es eben doch eine kreative Tätigkeit ist, eine ästhetische, eine künstlerische Tätigkeit.

Ihr habt in eurem Buch geschrieben – und das liest man ja überall –, die höheren Programmiersprachen, also vor allen Dingen auch die objektorientierten Programmiersprachen seien Programmiersprachen, mit denen man dem Computer mitteilt, was man eigentlich tun will. Ich würde genau den umgekehrten Weg gehen und würde sagen: Nein, diese höheren Programmiersprachen dienen dazu, dem nicht programmierenden Management klarzumachen, was man eigentlich tut. Es geht nämlich nicht um die Lesbarkeit des Programm-Codes für den Computer, es geht um die Lesbarkeit des Programm-Codes für die Leute, die Programmierer managen. Man müsste mal darüber nachdenken, wie eigentlich die ganze Entwicklung von diesen Modeling Tools – also die Tools, die Code visualisieren, Codestrukturen visualisieren – wie das eigentlich mit diesem Krieg zusammenhängt, den die Programmierer seitdem permanent gegen das Management führen, das sie organisiert, das sie überwacht und das auch die Unternehmensziele festlegen will.

Noch vor wenigen Jahren gab es eine neue, stark von IBM und Microsoft getragene Initiative, die einigen Wirbel in der Branche verursacht hat. Das waren die sogenannten Software Factories. Zusammen mit einer neuen Initiative für Modeling Tools, die damals von Microsoft im Rahmen des Team Foundation Server entwickelt wurden. Und gleich im Gegenzug hat sich da die sogenannte Code-First-Bewegung von Entwicklern, die Clean-Code-Entwicklerbewegung gebildet. Auch mit Sichtbarkeit und auch mit einigem Einfluss. Da haben die gesagt “Nein, wir wollen nicht erst irgendwas modellieren und irgendwelche schöne Graphen machen, die wir dann dem Management auch schön erklären könne und wir wollen das Ganze nicht nach dem Wasserfall- und nach dem Rational Unified Prozess machen. Wir wollen erst mal coden. Wir wollen mit dem Code anfangen.” Man muss mal über den Krieg nachdenken, der jetzt seit längerer Zeit zum Beispiel über objektrelationale Mapper in Datenbanktechnologien geführt wird. Wo die Programmierer immer wieder sagen “Wir wollen mit dem Code anfangen. Wir wollen erst mal hier unsere Klassen bauen. Und wir wollen unsere Systeme zusammenbauen und dann wollen wir uns erst überlegen, wie wir das Ganze sozusagen auf die relationalen und hierarchischen Datenbankstrukturen des Unternehmens abbilden.” Wohingegen so aus der Richtung des Softwaremanagements immer kommt: “Nein nein, wir müssen erst mal die relationalen und die hierarchischen Datenbankstrukturen festlegen, und dann können wir uns überlegen, wie wir unsere Systeme darauf bauen.”

Hier sind permanent solche Konflikte im Gange, über die man mal mit einem ganz anderen Instrumentarium nachdenken müsste als mit der klassischen Technikgeschichte, die derzeit aber noch vorherrscht. Dazu müsste man über Werkzeuge der Arbeitssoziologie zum Beispiel nachdenken, über die Geschichte des Arbeitswesens, auch dazu gibt es was. Man müsste auch darüber nachdenken, was Programmierer eigentlich konkret den ganzen Tag tun. Und wie das doch konfliktbeladene Verhältnis aussieht zwischen akademischer Informatik und den praktischen Programmierern, die da überall in den Unternehmen und Behörden rumlaufen. Das ist nämlich durchaus konfliktgeladen, von Anfang an. Schon auf dieser Konferenz zum Beispiel, auf dieser zweiten Konferenz 1969 in Wien, sagten die Vertreter der Programmierer, also die Leute, die die Software in den Unternehmen schrieben, sie fühlten sich behandelt wie Affen, die im Käfig angeschaut werden. Das hätte so alles überhaupt nichts mit ihren täglichen Problemen und Bedürfnissen zu tun.

Tatsächlich muss man ja auch sagen, dass es der Informatik nicht gelungen ist, bis heute – vielleicht heute noch weniger, als vor zehn oder vielleicht auch zwanzig Jahren – die Professionalisierung, Institutionalisierung wirklich für sich zu gewinnen. Denn dazu würde ja als Erstes gehören, dass sie bestimmen können, wer über ihre Bildungszertifikate und Bildungsdiplome den Eintritt in den Arbeitsmarkt erhält. Das ist ja überhaupt nicht der Fall. In den Unternehmen, in den IT-Abteilungen, da läuft ja alles mögliche rum. Wir zwei sitzen hier, du hast selber neulich noch geschrieben, du hast zehn Jahre lang am heißen Herd gestanden und programmiert. Du bist Literaturwissenschaftlerin, ich bin Philosoph, Historiker und Soziologe. Und wir sind ja keine Einzelfälle. Im Gegenteil, ich vermute, die meisten Leute, die dein Buch lesen werden, sind keine Informatiker, sondern sind die wirklich vielen Leute, die aus den Geisteswissenschaften oder aus ganz anderen Wissenschaften da reingerutscht sind. Und das ist viel eher typisch für die große Masse der Leute, die ihr Leben mit Programmieren verbringen.

Natürlich gibt es auch die Hardcore-Informatiker, das sind die Leute, die natürlich an Algorithmentheorie arbeiten, die an numerischer Analyse arbeiten. Das sind die Leute, die Compiler schreiben, das sind die Leute, die an AI arbeiten oder an der Semantik von Programmiersprachen. Aber es sind relativ wenige Firmen, wo diese Leute unterkommen, mittlerweile, es sind dann die großen: Es ist Microsoft, es ist IBM, es sind die paar großen Hardwarehersteller wie Intel, wo dann eben zum Beispiel Compiler-Hersteller unterkommen. Aber es konzentriert sich eigentlich auf wenige Firmen, es ist nicht die Masse der Programmierer. Und ich finde es erstaunlich, wie wenig über die vielen Leute geforscht wird, diese 40 Millionen Menschen, die über das, was sie tun, über ihre tägliche Arbeit doch einen großen Anteil an dem haben, was wir eben die Computerisierung nennen, und eine Welt geschaffen haben, in der wir heute leben, die zum guten Teil bestimmen, wie wir miteinander interagieren, wie wir mit der Welt interagieren, welche Selbstbilder wir von uns selbst entwerfen und die insgesamt einen riesigen Einfluss auf unsere heutige Zeit haben. Das findet zu meinem Erstaunen kaum statt.

Lies irgendeinen, den Balzert zum Beispiel, das Standardlehrbuch für Software Engineering, da wirst du nichts, aber auch wirklich gar nichts von dem finden, über was wir zwei uns gerade hier unterhalten oder worüber ich gerade monologisiere. Gibt’s nicht. Es gibt ein bisschen was bei Wolfgang Coy, der Anfang der achtziger Jahre ein bisschen was darüber publiziert hat. Aber der publiziert darüber auch nicht mehr. Mit dem könnte man sich aber auch mal unterhalten über die Sachen. Also jetzt – nur als ein Beispiel, es wäre interessant, darüber nachzudenken, was denn für Überlegungen hinter der Entwicklung der objektorientierten Programmierung stecken, die eben auch in diesem Zeitraum passiert, Ende der siebziger Jahre. Die Ziele, die dahinter steckten, waren: Man kann alles schön kapseln, man kann alles in so Komponenten verpacken, Komponenten, die man dann ähnlich wie elektrische Komponenten auf so eine Leiterplatte einfach aufstecken und miteinander verlöten und dann austauschen kann. Dass man so ähnlich mit Software verfahren könnte, das ist nämlich im Prinzip ein fordistisches Modell, was dahinter steckt. Und es wurde auch von Anfang an so gesehen, dass die Entwicklung der objektorientierten Programmiersprachen die Entsprechung des Fließbandes für die Programmierentwicklung oder für die Softwareentwicklung wären. Auch das ist immer wieder propagiert worden und wird nach wie vor immer wieder propagiert, in immer neuen Wellen. Richtig geklappt hat das aber eigentlich nie. Und es wäre interessant, wie politökonomische … das klingt jetzt sehr marxistisch, aber von mir aus klingt es halt marxistisch; ich will das ja gar nicht abstreiten, dass die Unternehmen auch Geld damit verdienen müssen. Wie sich das bis in den Entwurf, das Design, die Semantik, bis in einzelne Programmiersprachenkonstrukte durchzieht.

Ein typisches Beispiel wäre die Abwertung von goto, die auch zu diesem Zeitpunkt stattfindet. Wo dann immer gesagt wird: Das führt zu unendlichem Spaghetti-Code, der dann nicht managebar ist. Aber von wem eigentlich nicht managebar ist? Da müsste man eigentlich viel mehr darüber nachdenken, das alles versuchen, zusammenzubringen, anstatt nur zu sagen, na ja, es gibt strukturierte Programmierung und daraus hat sich dann irgendwie die objektorientierte Programmierung entwickelt. Ja, wie denn? Warum denn? Was steckt denn dahinter?

Erst in den siebziger Jahren, erst als die Informatik sich als Wissenschaft zu etablieren und zu institutionalisieren sucht, und zwar indem sie sich gegen andere Wissenschaften abzugrenzen sucht, als dann die ganze Algorithmentheorie kommt – erst in dem Moment kommt dann Turing hoch, erst in dem Moment kommt dann auch dieses abstrakte Computermodell hoch, der Von-Neumann-Rechner. Wo man sagt, uns ist die eigentliche physikalische Implementierung egal, wir machen jetzt die Informatik als abstrakte Wissenschaft. Erst dann wird das abstrakte Computermodell überhaupt erst etabliert und als Kern der Informatik beschrieben. Obwohl das, das muss man dazu sagen, für die eigentliche Geschichte des Programmierens, wie wir sie grade skizziert haben, null relevant war. Null.

Und wenn du dir jetzt anguckst, wie dann seit den Siebzigern, spätestens seit den achtziger Jahren die Kulturwissenschaftler, die ja im Prinzip alles davongelaufene Literaturtheoretiker sind – nehmen wir jetzt mal Kittler – genau auf diesen Zug aufspringen. Weil sie glauben, dass sie die klassische Hermeneutik überwinden können, weil sie jetzt ein neues Modell gefunden haben, wo dann die ganzen Diskurse sich sozusagen materialisieren. Nämlich in diesen Rechnern, in diesen ganzen Rechnerstrukturen und diesen ganzen Algorithmen, und in diesen ganzen universellen Maschinen. Und wenn du dir da anguckst, dass Kittler dann einen Aufsatz schreibt, der heißt ‚Es gibt keine Software’. Wo ich sagen würde, es gibt eigentlich nur Software.

Man muss sich wahrscheinlich irgendeinen Turn dafür ausdenken. Ich nenne es dann den … keine Ahnung, wie ich diesen Turn nenne, aber wenn man über die Geschichte der Software nachdenken will und wenn man darüber nachdenken will, wie Software unsere Welt strukturiert und bestimmt, dann braucht man so eine Art Realismus-Turn. Man muss weg von Konzepten, die im Prinzip alle von davongelaufenen Literaturtheoretikern stammen. Und man muss dann eben auch weg von Kittler, der uns in dem Moment überhaupt nicht weiterhilft.

Ich merke nur, da ist irgendwas. Da ist nicht nur Rauch, da ist irgendwo auch Feuer. Und da muss ich dranbleiben. Und ich komme dann über alle Umwege, die ich ja mittlerweile gemacht hab, eben auch wieder zurück auf das Thema, weswegen ich eigentlich ursprünglich mal angetreten bin. Denn das war ja ursprünglich meine Frage: Was machen wir denn hier eigentlich den ganzen Tag als Programmierer? Oder überhaupt als IT-Branche insgesamt? Als Evangelist erzählst du immer nur: “Es ist neuer, es ist schöner, es ist besser, es ist schneller!” Aber es steckt doch eigentlich mehr dahinter. Man kann bis in ganz aktuelle Entscheidungen – zumindest der Technologie, die ich sehr gut kenne, das ist die Microsoft-Technologie – hineingehen und fragen: Warum gibt es jetzt diese Apps? Und warum ist die Windows-IT-Infrastruktur, die jetzt neu gebaut worden ist, so, wie sie ist? Das ist ja nicht einfach nur, weil es jetzt irgendwie besser ist als früher, sondern es stecken ja noch ganz andere Interessen dahinter. Es stecken ganz andere Ziele und Pläne dahinter. Die Praxis des Programmierens ändert sich derzeit stark. Und niemand beschreibt das.


5 Kommentare

  1. Benni sagt:

    Wir bloggen bei uns auf keimform.de schon länger immer mal wieder über solche Fragen. Z.B. hier:

    http://keimform.de/2008/re-taylorisierung-in-der-it-industrie/

    oder hier

    http://keimform.de/2009/scrum-software-toyotismus/

  2. MX sagt:

    Ansätze, Software und Gesellschaft zusammen zu denken, gibt es z.B. in den „Critical Code Studies“, „Software Studies“ oder allgemeiner „Digital Humanities“ oder auch die Frauensache in der „feministischen Techniksoziologie“. Hin und wieder gibt’s Einzelanstrengungen wie der schnell wieder verschiedene „Ressourcen rebellieren“-Blog zur kritische Soziologie der Software-Entwicklung“ bspw. über Re-Taylorisierung. Jedenfalls alles ziemlich marginal.

  3. fish sagt:

    Das trifft doch wirklich nicht auf die ganzen neuen Firmen und Startups zu. Agile development, Scrum und Co hat mittlerweile auch Einzug in die großen Firmen gehalten. Jeder Schlipsträger weiß, dass ihr Wasserfall-Entwicklungzyklus nicht funktioniert. Quantitative betrachtet mag das noch immer die Minderheit sein, aber die Firmen die erfolgreiche Software-Projekte entwickeln setzen sich seit Jahren mit genau diesen Fragen auseinander.

    1. MX sagt:

      Die Befassung mit Agilität ist auf der Arbeitsweltebene m.W. ebenfalls unkritisch. Auf dieser Ebene fällt mir spontan nur das Contemplative Programming ein, das sich mal kritisch mit der Hetzerei des Extreme Programmings auseinandersetze.
      Eine Praktik wie das Fulltime-Pair-Programming, das frühes Feedback und dadurch kostengünstige Fehlerbeseitigung ermöglichen soll, dient bspw. gleichzeitig zur gegenseitigen Disziplinierung zur Arbeit. Es braucht keine Kamera- oder Computer-/Arbeitszeitüberwachung mehr, die Kontrolle steckt in der Arbeitsorganisation und wird von den Überwachten selbst freiwillig vollzogen. Daran scheitern auch die üblichen Beschwerden über Arbeitplatzkontrolle. Welcher Geist hier am Werk ist, das kann man bei Obie Fernandez nachlesen, z.B. in „10 reasons pair-programming ist not for the masses“. Fernandez beschreibt dort affirmativ die agile Organisation seines Unternehmens, lobt die Disziplinierungseffekte (kein privates Surfen, mehr Tempo, kein Slacking, …) und lässt eine dazu passende Arbeitsideologie und -moral durchblicken: Wär halt nur was für die Elite, für die High-Achiever und die Ehrlichen. Lediglich Arbeitszeitbetrüger wollten sich solchen Praktiken entziehen.

      Pair-Programming hat noch andere Effekte, etwa die Verteilung von Wissen, so dass einzelne Entwickler bei Ausfall (oder Kündigung) kein Wissen „mitnehmen“ und entbehrlicher werden. In einer Welt ohne Lohnarbeitskonflikte wäre das auch wenig zu beanstanden.

      Vor einigen Jahren besuchte ich ein Unternehmen, in dem es keine Türen mehr gab und die Computer so gestellt wurden, dass jeder Arbeiter die anderen im Rücken hatte, also nie sicher sein konnte, gerade nicht beobachtet zu werden und entsprechend sein Verhalten darauf einstellte. Agilisten beschreiben hier lediglich den kommunikativen Nutzen: Cockburn bspw. im Buch „Agile Software Development“ als „osmotische Kommunikation“ – jeder hört alles, jeder kann früh Feedback geben oder bekommt mit, was gerade los ist.

  4. Herr Rau sagt:

    Sind Programmierer mit Autoren von Fiktion (oder Werbetextern?) zu vergleichen? Um die kümmert sich ja die Literaturtheorie fast ebenso wenig wie die Informatik um die Programmierer. Muss sie auch nicht. Aber die Sicht von Autoren ist oft aus anderen als literaturtheoretischen Gründen interessant, und zumindest bei Fiktion sind die bekannten unter ihnen auch lautstark und zu hören. (Sie schreiben ja auch gerne übers Schreiben.) Bei Programmieren ist das wohl anders. Wie sieht es mit einer Sozialgeschichte des Journalismus aus, ist das vergleichbar?

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *