Was Softwarestandards mit meinem Auto und Lafontaine zu tun haben
Softwarestandards sind in der IT so ein Thema. “Wenn alle dasselbe verwenden” ist vermeintlicher Katalysator für Tugenden wie Wiederverwendbarkeit, Teilen von Wissen, geringere Kosten und vereinfachte Ressourcenplanung. Die Idee ist: Wenn Programmiersprache, IDE, Bibliotheken und Werkzeuge in einer (Excel-) Liste als Standard definiert sind, sollen die Leute tunlichst nur diese verwenden und damit die Basis für die eingangs erwähnten Segnungen legen.
Blöderweise funktioniert das nicht. Es passiert einfach nicht.
Projekte verwenden ganz intuitiv, was aus ihrer Perspektive gut für sie ist. Du hast nur faktisch nur PHP-Programmierer? Dann wird dein Projekt in PHP starten, selbst wenn der Unternehmensstandard C# sein sollte. Eine Weile lang fällt das niemandem auf. Irgendwann ist das Projekt dann soweit, dass es in Betrieb geht. Die Diskussion “Wieso ist das PHP?” ignorierst du, denn die mögliche Konsequenz “Alles zurück auf Anfang” will niemand ernsthaft vertreten. Meistens kommst du damit durch.
Wir haben es hier mit zwei Problemen zu tun: In einer dezentralen Welt fällt es zunächst nicht auf, was irgendein Team am anderen Ende der Welt startet. Wer gedanklich noch in der IT der zentralisierten Grossrechner steckt, kan sich nur schlecht vorstellen, wie leicht man heute mit einer Kreditkarte und ein wenig Chuzpe alle Compliance-Prozesse auf einmal umgehen kann. Da alles in der Cloud ist, ist nichts vor Ort. Oder gar in Sichtweite. Kontrolle ist schlicht unmöglich. Das war auf dem Mainframe anders.
Zum zweiten fehlt es an Sanktion. Die sind eigentlich wesentlicher Bestandteil von Standards. Wie zb “Du sollst deinen König nicht beleidigen” (Sanktion: Kopf weg) oder “Du sollst im Ort nicht schneller als 50 km/h fahren” (Sanktion: Geld weg). Wer nicht sanktioniert, hat keine Durchsetzungskraft.
Wenn also zum einen die Kontrolle fehlt, die Leute also a priori machen was sie wollen, und zweitens die Sanktion fehlt, dann wird das Ergebnis nicht die gewünschte Standardisierung sein.
Die Lösung für dieses Problem lautet “Motivation”. Nur wenn die Menschen per eigener Motivation das Gewünschte tun, kann man mit dem Zustand der fehlenden Kontrolle leben und gleichzeitig auf Sanktionen verzichten. Hier kommt Oskar Lafontaine ins Spiel, er beschrieb das 1995 auf dem SPD Parteitag so:
Wenn wir selbst begeistert sind, können wir auch andere begeistern.
Das Geheimnis ist unsere eigene Überzeugung, unsere eigene Begeisterung. In einer dezentralen, sanktionsfreien Welt können wir uns unsere Standards in die Haare schmieren, wenn wir nicht selbst davon überzeugt und begeistert sind. Eat your own dogfood sagt man, oder auch Practice what you preach. Wer Standards für andere Entwickler festlegen möchte, sollte diese als Entwickler tunlichst selbst verwenden.
Aber ich weiss doch gar nicht
Du sagst: “Aber ich bin kein Entwickler, wie soll ich das denn leisten?”
Ich sage: Dann gib keine “Standards” für andere heraus, die das Papier nicht wert sind, auf dem sie einmal ausgedruckt wurden.
Um dich zu beruhigen, möchte ich hinzufügen: Die anfangs erhofften Vorteile treten sowieso nicht ein. Weder ist Wiederverwendbarkeit dadurch gekennzeichnet, ob zweimal die gleiche Programmiersprache verwendet wurde (Stichwort: Lose Kopplung ist besser) noch teilt sich Wissen leichter, einfach indem alle den gleichen Compiler benutzen. (Stichwort: Kultur) Kurz: Schon der Ansatz ist ungeeignet. Was man stattdessen gern als Standard vorgeben möchte, sind eher Aspekte wie diese:
- Was immer du verwendest, wirst du selbst betreuen/warten/pflegen müssen. Das gilt für die gesamte Lebensdauer der Daten, die in deinem Projekt liegen.
- Mach dich nicht abhängig ohne gleichlautende Garantien. Das gilt für kommerzielle Software genauso wie für OpenSource Software.
- Mach Daten lesbar und Funktionen zugänglich. Nur so bleibst du handlungsfähig. Das führt zu Industriestandards und offenen Schnittstellen.