Vom Messdiener zum digitalen Ketzer

Da saß ich, Anfang der 2000er mit einem seitenstarken Wälzer aus dem Microsoft-Press Verlag.¹ Stolze 129,- DM war damals der Preis. Ich blätterte da so und verspürte ein Déjà-vu: Die Seiten kannte ich doch. Nicht im inhaltlichen Sinne. Von der Aufmachung, der Form, den Beispielen bis hin zu den Icons der Hinweisboxen: Da sind die verlorenen Handbücher der 90er Jahre!

Okay, jetzt muss ich für die heutige Generation etwas weiter ausholen: Software gab es früher in großen Verpackungen. Zusammen mit auf Papier gedruckten Büchern. Das waren anfangs dicke Ringbuchmappen, später schwere Wälzer aus hauchdünnem (und scharfen) Bibelpapier. Über Nacht verschwanden diese auf CD-ROMs, später in das noch junge Internet hinter den ersten Paywalls.

Das war die exklusive MSDN-Mitgliedschaft.² Ein Club für alle, die bereit waren jährlich für die Entwicklerprogramme von Microsoft vierstellige Beträge zu zahlen. Die Vorläufer der heutigen Abo-Modelle. Glücklicherweise für Studenten mit Uni-Nachweis (fast) kostenlos und sogar gewerblich nutzbar.

Da saß ich nun, hielt die verlorenen Handbücher als Schulungsmaterial in meiner Hand und verspürte das unbestimmte Gefühl: Hier stimmt was nicht.

Willkommen im Vendor-Kult

Microsoft umgarnte Entwickler sehr intensiv, sprach von technologischen Partnerschaften, schickte Einladungen zu den typischen Road-Shows von Neuvorstellungen. Zusammen die Welt und das neue Jahrtausend im Sturm erobern. Wir Entwickler sollten der Schlüssel dazu sein. Weltbekannt der “Developers, Developers, Developers” Aufruf von Steve Ballmer aus dem Jahr 1999.³

Ich war Anfang 20 und glaubte alles. Microsoft stand mit dem Release von Windows 2000 in seinem technologischen Zenit. Ich folgte den Einladungen und war überzeugt, als Microsoft Certified Solution Developer (MCSD)⁴ besser an Projekte und Kunden zu kommen. Dem aktuellen Microsoft Schema folgend entspricht das einem heutigen App Builder.⁵

Doch den Kunden war das alles egal, sie wollten Probleme gelöst haben. Niemand fragte nach einem Zertifikat. Noch weniger bestand die Bereitschaft, deswegen höhere Stundensätze zu zahlen. Als ich das mit einem “Ask the Expert” bei einer Veranstaltung in Karlsruhe thematisieren wollte, bemerkte ich die atmosphärische Veränderung. In wenigen Sekunden von offen, motivierend und freundlich zu einem kühl, reserviert und vorsichtig.

Da war es wieder, dieses unbestimmte Gefühl, hier stimmt was nicht.

Werde ich ausgebeutet?

Die Microsoft-Exams waren damals produktgebunden. Windows Server 2000? Sorry 2003 ist raus, bitte Geld und Zeit nachwerfen. An den grundlegenden Konzepten hat sich jedoch kaum was verändert. Noch weniger an der Win32 API. Die heilige Kuh der Rückwärtskompatibilität verhindert allzu große Schritte bis heute. Jedes Windows 11 und 2025 Server baut auf die seit 2003 unveränderte MMC mit Ihren Snap-Ins.⁶ Nur ein programmiertechnisches Beispiel:

Windows-Dienste mit vollständigen Beschreibungstexten im Dienst-Manager lassen sich nicht in einem Gang erstellen. Es gibt im .NET Framework keine Methoden zum Erstellen oder Entfernen. Wir müssen runter zur Win32 SCM API⁷ mit CreateService() einen Dienst erstellen und dann in einem zweiten Schritt auf dem gleichen Handle mit ChangeServiceConfig2()⁸ den Beschreibungstext setzen. Man beachte die “2” im Namen, denn ein ChangeServiceConfig gibt es auch. Alles eingebunden in zusätzlichen Sicherheitsabfragen. Ein CreateService() zuvor könnte schief gelaufen sein. Und die eigene Anwendung crasht spätestens beim Versuch, auf einen NULL-Handle zuzugreifen.

Bis heute gilt die Heuristik: Leere Beschreibungstexte in Windows-Diensten sagen sehr viel über den Programmierer bzw. Softwarelieferanten.

Ich kann mich nicht erinnern, solche Details jemals in einem Exam oder aus einem Buch entnommen zu haben. Selbst nicht aus dem Petzold⁹, der Win32 Referenz-Bibel. Sowas lernt man nur in der Praxis und in Umgebungen, wo nicht husch husch Software rausgehauen wird, sondern wo Stabilität und Qualität wichtig sind. Attribute, die ich immer weniger in einem Kontext mit Produkten aus Redmond bringen konnte.

Da war es wieder, dieses unbestimmte Gefühl. Das kann doch alles nicht normal sein.

Zertifizierte Inkompetenz

Bei mir fiel irgendwann zwischen 2005 und 2007 der Groschen, ein zertifizierter Microsoft Partner zu sein war wie eine Kirchenmitgliedschaft im Mittelalter: Du zahlst Deinen Zehnten, wirst Teil einer Gemeinde und sofort exkommuniziert, wenn Du es wagst, kritische Fragen zu stellen.

Und das Zertifikat selbst? Es prüfte die Kenntnis von Produktfeatures, nie das Verständnis von Architektur, Codequalität oder sowas wie gesunden Menschenverstand.¹⁰

Ich begegnete im Laufe der Jahre vielen, die jede Menge Exams gesammelt hatten, aber in Ihrem Code kein einziges try..catch Exception Handling¹¹ hatten und denen SRPs¹² unbekannt blieben. Voller Überzeugung von Silverlight sprachen, nur um nachher schweigend festzustellen, dass Microsoft es nach drei Jahren wieder einstampfte.¹³ Das ganze Spiel wiederholte sich mit Metro, dann UWP, dann WinForms, dann… ja, was eigentlich?

Das Nachplappern von Trends, das Verfolgen einer erratischen Produktpolitik ist nicht normal, es ist für einen Dienstleister sogar höchst ungesund.

Vom Glauben abgefallen

Heute, viele Jahre später, sehe ich alles klarer: Was ich erworben hatte, war nicht Wissen, es war Symbol der Loyalität mit dem Anstrich eines Kompetenznachweises. Keine Bildung, sondern Bindung. Man könnte auch von Kontrolle oder noch böser von einer kompetenzsimulierten Wertschöpfung reden, natürlich nur auf Microsofts Seite.

Seit 2007 bin ich raus aus sämtlichen Mitgliedschaften und Partnerprogrammen. Dieses Bild meines HomeOffice Arbeitsplatzes dokumentiert das letzte von mir produktiv eingesetzte Windows. Auf den Sprung auf Windows Vista verzichtete ich.

Kurioserweise löse ich weiterhin Probleme mit Microsoft-Technologien und Infrastrukturen. Der Unterschied: Ich folge den Anforderungen der Kunden und ziele auf Nachhaltigkeit und echte Problemlösungen, frei von Produktpolitik, frei von einem religiösen Vendor-Kult.

Die verlorenen Handbücher von damals stehen noch immer in meinem Bücherregal. Als Erinnerung an eine längst vergangene Epoche aber auch als Warnung, nie wieder mit solchen unbestimmten Gefühlen arbeiten zu wollen.

Mein Tech-Stack und Toolchains sind frei und können von niemanden gesperrt werden. So wie das unlängst zahlreichen Microsoft-Partnern widerfahren ist.¹⁴

Ich sitze heute mit einem Kaffee an meinem GNU/Linux Arbeitsplatz, arbeite mit und an freier Software, auf den Schultern von ganz vielen anderen freien Lösungen, zum Wohle der Gemeinschaft.

Es war ein weiter Weg aber jetzt stimmt alles.

In diesem Sinne,
Tomas Jakobs