Software Systeme - auf Sand gebaut?

Im Februar 1998 hielt ich zusammen mit meinem Freund Dr. Bernhard Scheffold einen Vortrag am Institut für Informatik und Gesellschaft in dem wir die Rolle sozialer Strukturen in der Software Entwicklung betonten. Wir wollten herausfinden woran unser Projekt gescheitert war, warum wir z.B. alte und neue Mitarbeiter nicht integrieren konnten. Oder warum andere Abteilungen nicht zur gemeinsamen Frameworkentwicklung zu gewinnen waren.

Wir entdeckten dass soziale Reibungspunkte häufig dadurch zustande kamen dass soziale Grenzen entlang technischer Interfaces gezogen wurden (klassisch: Operating System vs. Applications). Und wir haben eine soziale Organisation vorgeschlagen die soziale und technische Interfaces überlappend organisiert und in der semi-formale Techniken wie Design Patterns bewusst auf Grund ihrer kommunikativen Wirkungen eingesetzt werden.

In 2000 hielten Bernhard und ich einen Vortrag beim SPIQ Jour Fix über den Wert von Methodologien der Software Entwicklung. Zu diesem Zeitpunkt galten prozessorientierte Ansätze wie V-Modell oder RUP bereits häufig als Garanten für erfolgreiche Softwareentwicklung.

Für uns jedoch reflektierten diese Ansätze keineswegs die Realitäten der SW-Entwicklung wie wir sie erfahren hatten. Und wir entgegneten, dass jede erfolgreiche SW-Methodologie die Entwickler ins Zentrum rücken muss. Schliesslich sind sie es die am Ende die Arbeit leisten müssen.

Es hat uns natürlich stolz gemacht dass wir die soziale Bedingtheit der SW-Entwicklung bereits zu einem Zeitpunkt erwähnten als Xtreme Programming den Durchbruch noch nicht geschafft hatte. Aber wenn wir jetzt auf unsere Vorträge zurückblicken müssen wir erkennen dass unser Horizont des Sozialen sehr eng auf die Grenzen von Teams oder Firmen eingeschränkt war.

Open Source wurde sehr populär und begann Druck auf die Qualität kommerzieller Produkte auszuüben. Kein Wunder, mehr Menschen waren finanziell unabhängig und konnten umsonst an Open Source Projekten mitarbeiten. Die Methodik der Open Source Projekte stellte ebenfalls einen Kontrapunkt zu den Prozessorientierten Methoden dar die die Software Entwicklung (und damit auch die Entwickler) in eine "Commodity" verwandeln wollten.

Die Krise der Internet Ökonomie setzte vielen IT-Projekten ein Ende und veränderte Kultur und Atmosphäre innerhalb der IT beträchtlich: Technologie wurde in Bezug auf ihren ROI bewertet und Entwicklungsgelder wurden knapp. Noch schlimmer: Management entdeckte das Sparen als Vision. Aber das war nur die gerechte Strafe für uns IT Spezialisten die das Geld auf verrückten Projekten verschwendet hatten. Gerechterweise muss man sagen dass dieser technologische Neo-Conservatismus (ganz im Gegenteil zu dem weiter unten erwähnten) durchaus zu einer Verbesserung der Softwarequalität führte: Nicht jeder technische Schwenk wurde mehr in den Firmen unmittelbar in halblebige Produkte umgesetzt und ältere Technologien erhielten etwas Zeit zu reifen. Es wurde auch uns IT Leuten klar dass neue Technologien doch wesentlich mehr Zeit brauchten bevor sie in grossen Projekten eingesetzt werden konnten.

Doch Anlass zu echter Beunruhigung war nicht gegeben: Wir würden niemals unsere Jobs verlieren und für unsere soziale Arroganz bestraft werden, oder?

Die Rolle der IT erfuhr im Anschluss an 9/11 eine Erweiterung: Nationale Sicherheit wurde zur Aufgabe. Ein lange nicht gesehener Anschlag auf Bürger- und Menschenrechte erfolgte zwischen Guantanamo Bay, Patriot Act und dem Irak Krieg - und Deutschland folgte in vielen Fällen wie z.B. der Auslieferung von Flugpassagierdaten an die USA (gegen nationales Recht).

Seitdem scheinen alle Dämme gebrochen. Anonymität als Recht (man denke an alte Versionen der deutschen Gesundheitskarte, bei der es Apothekern nicht erlaubt war die Namen der Patienten zu lesen) wurde eine verdächtige Forderung. Und jetzt wollen mehrere Europäische Staaten generell alle Telekommunikations- und Internetdaten ALLER Bürger ohne jeden begründeten Verdacht für mindestens drei Jahre speichern - aus Gründen des Terrorismus und der Kinderpornographie natürlich). Toll Systeme werden nicht nach dem Prinzip des geringsten Aufwandes sondern der maximalen Datenerhebung entwickelt.

Im Oktober 2004 habe ich eine Vortrag zur Security beim SPIQ Jour Fix gehalten. Die Qualität der Applikationen hat sich in Bezug auf Security Probleme nicht gross geändert wie z.B. das T-COM OBSOC Beispiel zeigt. Was sich geändert hat ist dass mich diese Schwäche der Softwareentwicklung nicht mehr gross berührt: Es handelt sich meist um ein IT-internes Problem und die Gefahren für die Öffentlichkeit sind gering.

Was mir Angst macht ist dagegen ist erfolgreiche Softwareentwicklung wenn sie eingesetzt wird um bürgerliche Rechte zu beseitigen. Der Datenschutz aus Gründen der Privatheit scheint verschwunden zu sein. Hartz 4 z.B. bringt umfangreiche Datenabgleichung zwischen mehreren öffentlichen aber auch privaten Organisationen. Bürger werden biometrisch vermessen und idiotische Sicherheitsideen machen sich breit.

So lange die Qualität der Softwaresysteme in Bezug auf unsere Freiheit nicht thematisiert wird, freue ich mich über jedes Toll-Collect Desaster, über Probleme bei der Job-Karte oder Gesundheitskarte. Und auch wenn die totale Erfassung der Kommunikationsdaten der Bürger ein softwaretechnischer Erfolg wird, ist doch die Qualität der Ergebnisse in mehrerer Hinsicht fragwürdig.

Die Frage nach der Qualität von Software Systemen stellt sich nach wie vor. Ohne Zweifel wurden in den letzten 10 Jahren grosse technische Fortschritte gemacht, nicht zuletzt durch Dinge wie Open Source Software, Design Patterns, Xtreme Programming, Framework Technologie und neuen Programmiersprachen (Wenn auch vieles weit weniger neu war als man gemeint hat). Aber es ist Zeit dass wir neben der technischen Qualität auch die soziale und politische Qualität unserer Software Systeme verbessern. Die großen Software Systeme zur Auswertung und Verwaltung der RFIDs - die soeben eingeführt werden - wären hierfür gute Kandidaten.