Microsoftdämmerung

Ich habe nichts gegen Microsoft. Ich habe sogar alles für Microsoft. .NET 3.5 ist cool. VS2008 ist cool. F# ist cool. VSTO und SharePoint sind cool. Sicher, da gibt es Bugs und Imperfektionen, aber was soll´s? Wer im Glashaus sitzt, wirft besser nicht mit Steinen.

Im Großen und Ganzen fühle ich mich in Bezug auf Microsoft also positiv gestimmt und dennoch unideologisch. Pauschal gegen Microsoft bin ich nicht, wie das Bisherige deutlich machen sollte. Microsoft ist nicht auf der "dunklen Seite der Macht". Pauschal für Microsoft bin ich aber auch nicht. Es gäbe viel zu verbessern am Existierenden, es gäbe viel zu tun, was Microsoft (noch) nicht tut.

Aber auch wenn ich den Eindruck von mir selbst habe, recht neutral zu sein (mal abgesehen von meiner grundsätzlichen Plattformentscheidung für .NET und gegen Java oder C++, was aber nur mit meiner Unfähigkeit zu tun hat, mehr als eine Plattform ausreichen gut zu kennen), so merke ich in diesen Tagen doch, dass ich es de facto nicht bin. Ich leide nämlich an Microsoft Bias.

Microsoft Bias ist eine Erkrankung der Wahrnehmungsorgane.  Sie engt das Blickfeld ein, lässt alles, was Microsoft produziert größer und im Vordergrund erscheinen, andere Entwicklungen erscheinen kleiner, unscharf und nur am Rande. Der Microsoft Bias ist eine schleichende Erkrankung, die insbesondere Entwickler befällt, die über längere Zeit ausschließlich Software mit Microsoft-Werkzeugen entwickeln. Besonders häufig ist der Microsoft Bias bei denjenigen, die ihre Entwicklertätigkeit auf der Microsoft-Plattform vor dem Jahr 2000 begonnen haben.
Der Microsoft Bias ist eine im Regelfall gutartige Erkrankung mit gut Aussichten auf Heilung. Gelegentlich allerdings entwickeln sich daraus Extremformen wie Microsoft Hörigkeit oder Microsoft Hass. Beides sind Persönlichkeitsstörungen, die ein fast kompletter Verlust des peripheren Sehens charakterisiert; damit einher geht die für Persönlichkeitsstörungen typische Krankheitsuneinsichtigkeit gepaart mit unbewussten Abwehrmechanismen wie Rationalisierung und Intellektualisierung. Bei der Microsoft Hörigkeit ist der Erkrankte ganz auf Microsoft fixiert und blendet andere Informationsquellen komplett aus; beim Microsoft Hass ist der Erkrankte ganz auf Technologien und Informationsquellen außerhalb Microsofts fixiert und blendet Microsoft aus.

Microsoft Bias also. Ich nehme vor allem wahr, was Microsoft so tut und sagt. Oder etwas allgemeiner: Ich nehme vor allem wahr, was in der Microsoft nahen Entwicklergemeinde so getan und gesagt wird. Tatsächlich lese ich recht wenig Microsoft O-Ton auf MSDN Online, sondern eher Blogs und Zeitschriften und Bücher, die sich mit Microsofts Ideen und Technologien beschäftigen.

Das ist nun, wie ich festgestellen muss, beschränkend. Nicht wirklich gefährlich also, sondern nur einengend, den Horizont verkleinernd. Bis in die ersten Jahre des neuen Jahrtausends war Microsoft Bias noch nicht als Krankheit diagnostiziert, sondern nach Wahl der Microsoft-Plattform für die Softwareentwicklung quasi ein normaler und unausweichlicher Gesundheitszustand. Rauchen galt ja auch über Jahrhunderte nicht als Sucht, sondern als Vergnügen und Ausdruck aller möglichen positiven Eigenschaften von Geselligkeit über Intellektualität bis zu Tatkraft.

Nun haben sich die Zeiten aber gewandelt. Das Rauchen ist unzeitgemäß geworden. Es lebt der Mensch nun allgemein so lang, dass die Folgen des Rauchens nicht nur ihn, sondern auch die Krankenkassen belasten.

Und genauso unzeitgemäß ist ein Microsoft Bias als Haltung für die Softwareentwicklung selbst auf der Microsoft-Plattform. Es sind die Applikationen bzw. die Anforderungen an den Application Lifecycle so umfangreich, dass Microsoft bei allem guten Willen einfach nicht mehr tonangebend sein kann und sollte. Toll, was Microsoft alles macht und versucht zu stemmen. Aber wo zum Beispiel Phoenix noch im Forschngsstadium ist, da bieten Cecil und PostSharp schon lange produktionsreife Wege, um IL-Code zu verändern. Anderes Beispiel: Microsoft hat keine wirkliche Botschaft zu einem etablierten Thema wie Aspektorientierte Programmierung (AOP) - aber es gibt Tools, die PostSharp oder Spring.NET. Oder noch ein Beispiel: Unit Testing. Inzwischen hat Microsoft Unit Test Features sogar in die Pro-Edition von Visual Studio gepackt - aber das war erstens sehr spät im Vergleich zu den Open Source Alternativen und zweitens ist diese Integration unvollständig. Unvollständig insofern, als dass Unit Testing ohne Code Coverage Analyse schnell ein Lippenbekenntnis bleibt. Mit den VS2008 Pro-Features allein ist also ein Start nicht zu empfehlen. Viel umfassender ist da die Unterstützung z.B. durch TestDriven oder TestMatrix. Beide umfassender als VS2008 Pro in Bezug auf Unit Tests, beide billiger als der Upgrade auf VSTS Developer mit mehr Unit Test Features.

Noch mehr Beispiele gefällig? Wie wäre es mit O/R Mapping? Da wo Microsoft heute mit Linq to Sql ist, waren die Alternativen wie Open Access oder Wilson O/R Mapper oder LLBLGenPro schon vor Jahren. Und es geht noch einfacher wie z.B. Persisor .NET oder db4o zeigen.

Oder wie stehts mit Dependency Injection? Erst in neuester Zeit (April 08) hat Microsoft hier wirklich Brauchbares in Form von Unity geliefert. Andere boten Gleichwertiges schon lange.

Oder wie stehts mit anerkannten Konzepten wie SEDA oder CEP? Von Microsoft ist nichts zu hören. Die CCR ist nur ein Ansatz einer kleinen Truppe, die um Aufmerksamkeit ringt. Was der Markt ansonsten zu bieten hat, erfahren die an Microsoft Bias Erkrankten nicht.  Dabei gibt es ein Entwicklerleben jenseits von Enterprise Services, WCF, WF und BizTalk. Schonmal von NServiceBus oder NEsper oder Jabber gehört? Wo die CCR nur über simple Joins komplexe Events "erzeugen" kann, öffnet NEsper als Event Stream Prozessor ganz neue Möglichkeiten. Da wo die BizTalk Services noch im Teststadium für die Verbindung von Diensten durch Firewalls sind, da ist Jabber schon lange produktionsreif - und Open Source.

Oder als letzte Stichworte statische Quellcodeanalyse und automatische Produktion. Microsoft bietet FxCop und TFS. Das ist nett. Aber viel weitreichender und dynamischer ist z.B. NDepend. Und CC.NET konnte die automatische Produktion schon lange vor TFS. Und FinalBuilder ist viel intuitiver als MSBuild. Oder wie stehts mit Trac oder OnTime? Können die womöglich dasselbe oder gar mehr? Vielleicht nicht so integriert wie TFS, dafür aber zu kleinerem Preis, unabhängig, mit mehr Features und früher als ein Produkt von Microsoft?

Soll ich weitere Bereiche aufzählen, in denen Microsoft nichts oder nur spät etwas bietet, Alternativen aber existieren,  die die "Microsoft Community" - oder sollte ich sagen: die Microsoft Bias Krankengemeinde? -nur wenig weiß? Es gäbe noch einige... Aber einerlei. Die entscheidende Frage ist doch, wie mit dieser Erkenntnis, der Krankheitseinsicht umgehen?

Es ist ja nicht schlimm, dass Microsoft der Entwicklung auch mal hinterherhinkt oder einfach keine Antwort geben will. Das ist völlig legitim. Microsoft ist ein Unternehmen mit wirtschaftlichen Interessen. Die mögen jedoch eben nicht (!) immer mit denen der Entwicklergemeinde übereinstimmen. Wenn Microsoft die eine oder andere Technologie pusht oder das eine oder andere Konzept proklamiert, dann heißt das nicht (!), dass dies dann auch das beste Angebot oder state-of-the-art ist. Kann sein, muss aber nicht. Und ist in Zukunft wahrscheinlich immer seltener der Fall.

Das hat aus meiner Sicht mit der schieren Komplexität des Metiers zu tun. Auch Microsoft kann bei aller Größe eben nicht (!) alle Aspekte der Softwareentwicklung in gleicher Qualität abdecken. Microsoft ist ein Riese, der immer noch einer zentralen Führung bedarf. Solche zentrale Führung ist aber quasi per definitionem nur zur Bewältigung einer gewissen Komplexität fähig. Deshalb wird ja auch die freie Marktwirtschaft in so hohen Tönen gelobt: Sie hat keine Führung und ist daher am flexibelsten. Microsoft agiert nun zwar in einer recht freien Marktwirtschaft, ist aber selbst kein freier Markt. Deshalb kann Microsoft allein eben nicht in allen Bereichen "das beste" bieten. Dafür ist viel mehr Flexibilität nötig, d.h. weniger Direktive und weniger Altlast. Das, was Microsoft auszeichnet - Rückwärtskompatibilität und Verzahnung - ist gleichzeitig auch Microsofts wachsender Hemmschuh.

Wie gesagt: das ist weder gut noch schlecht. Es ist halt die Natur der Sache. Microsoft halt keine Schuld an der Verbreitung des Microsoft Bias. Die Erkrankung ist eher eine, hm, Art Autoimmunerkrankung oder iatrogen. Entweder fügen wir sie uns selbst schleichend zu. Oder sie wird durch die Medien, die eigentlich unabhängig sein und beim Überblick auch jenseits von Microsofts Angeboten helfen sollen, verursacht.

Hier setzt denn auch meine Kur an. Geheilt werden wir vom Microsoft Bias nur durch einen bewusst weiten Blick, sozusagen Augentraining. Immer wieder sollten die einschlägigen Medien und Plattformen ihre Autoren und Referenten motivieren, nicht nur Microsofts Botschaft wiederzukäuen, sondern darüber hinaus zu blicken. Bücher über Linq to Sql oder BizTalk oder TFS gibt es. Warum aber keine oder deutlich weniger über Open Access, NServiceBus oder CC.NET und FinalBuilder? Das Gewicht der Berichterstattung ist stark zugunsten von Microsoft verlagert. Ein Übelstand, der der Entwicklergemeinde nicht gut tut.

Die recht neue Alt.Net "Bewegung" ist ein Ausdruck des Willens zur Gesundung. Gut so. Aber wir brauchen mehr Blicke über den Tellerrand hinaus. Ich habe mir deshalb vorgenommen, in Zukunft vermehrt über Technologien und Konzepte jenseits der Microsoft Botschaft zu berichten. Warum soll ich mich auch in den Chor der VSTS Verkünder einreihen, wenn TestDriven dasselbe oder gar mehr bietet - sogar für VS2008 Standard Anwender? Warum soll ich ins BizTalk Services Horn stoßen, wenn Jabber viel interessanter und vor allem hier und jetzt ist?

Damit will ich nicht sagen, was Microsoft tut, sei schlecht. Ich will nur mehr Entwicklern Alternativen aufzeigen, denen sie Beachtung schenken sollten. Wenn die Schnellen die Großen schlagen, warum soll ich dann nicht heute eine ordentliche non-Microsoft Implementation eines Konzeptes einsetzen, statt auf eine Lösung von Microsofts Gnaden dermaleinst zu warten? Ich bin dann lieber heute schneller, als morgen vielleicht etwas besser.

Je länger ich auch drüber nachdenke, desto eher bin ich bereit, Integration zu opfern für mehr Wahlfreiheit. Best-of-Breed mit suboptimaler Integration heute hat für mich mehr Reiz als bessere Integration in der Zukunft, bei der ich wahrscheinlich mehr zahlen muss.

Insofern sehe ich Microsofts Hauptaufgabe da, wo es um die Schaffung von Plattformen geht. Allen voran Visual Studio und .NET. Da ist es wichtig, dass Microsoft einen guten Job macht, um diese Plattformen erweiterbar zu halten. Die Visual Studio Shell ist für mich ein Zeichen in dieser Hinsicht (auch wenn Eclipse immer noch um Längen voraus ist).

Die "Gottgleichheit" Microsofts, die Definitionsmacht, die Bestimmung der Entwicklerschicksale sehe ich hingegen am Schwinden. Das mag sich nicht in direkt und sofort in den Verkaufszahlen von Office und Windows und SQL Server ausdrücken. Aber letztlich kann Microsoft einfach in Relation zu dem, was wir Softwareentwickler brauchen, nicht alles "wuppen". Microsoft als one stop tool provider hat ausgedient, muss ausgedient haben. Wer sich nicht vom Microsoft Bias erholt (ohne zum Microsoft Hasser zu werden) vergibt sich einfach Chancen. Die Welt ist bunter und bietet mehr, als Microsoft uns vorbetet und vormacht.

Das ist schon heute so - es muss nur eben die Entwicklergemeinde in ihrer Breite sehen. Das zu erreichen ist Aufgabe der Medien. Es liegt an ihrer Themenselektion, was die Augäpfel der Entwickler erreicht und was als "salonfähig" gilt. Wenn sich die formal unabhängige Berichterstattung und Präsentation dann aber auch wirklich unabhängig verhält, dann wird sich Microsofts Sonne dem Horizont nähern. Dann wird es zur Microsoftdämmerung kommen - einer notwendigen Dämmerung, wie ich meine. Denn so wichtig eine Sonne als Lebensspender und Leitstern ist, sie kann bei zu großer Strahlkraft auch blind machen und verdörren.

Microsoft ist ein Player am Markt wie jeder andere. Gut so. Das müssen wir nur noch auf breiter Front zu unser aller Nutzen wirklich verinnerlichen. Es gibt viele Alternativen, die eine Chance verdienen. Möge die beste gewinnen!