Rant: Ist das Patterns and Practices-Team nur eine Alibi-Mannschaft?

Written on May 06, 2008

An sich bin ich seit vielen Jahren mit den Produkten von Microsoft und der Linie, die Microsoft "fährt", immer sehr zufrieden gewesen - insbesondere natürlich, was .NET angeht, da dies teil meiner täglichen Arbeit ist.

Bis .NET Framework 2.0 stand ich Neuerungen gegenüber auf dem Standpunkt: "vielleicht noch nicht ideal, aber wir sind auch noch nicht bei der obligatorischen Version 3.0 angelangt".

Inzwischen gibt es für mich allerdings etliche Punkte bei .NET und Microsofts Strategie, die mich ernsthaft stören.

Da diverse Unterhaltungen im Messenger meine Meinung größtenteils bestätigen, möchte ich die Punkte hier zur Diskussion stellen:

  • YAHOO!: Ich würde für YAHOO! keinen Cent (nicht EURO und nicht $) ausgeben, YAHOO! ist über kurz oder lang gegen Google dem Tode geweiht, das wird auch ein Kauf durch Microsoft nicht ändern. Microsoft kauft mit YAHOO eine fremde (nicht im Sinne von unbekannt) Technologie ein, die integriert werden muss. Microsoft hat mit (ASP).NET jedoch selbst eine - wie ich jetzt einfach mal zu behaupten wage - bessere Infrastruktur im eigenen Haus.
    Es wäre imho wesentlich sinnvoller, wenn Microsoft nur einen Bruchteil der ca. 40 Mrd. US-$ einsetzen würde, um eine vergleichbare Plattform mit (ASP).NET in Eigenleistung zu etablieren. Dies wäre zudem eine wunderbare Referenz für die .NET-Technologie.
  • Ich habe keinen Bezug zu den Live-Produkten, allenfalls nutze ich Live Maps, den Writer und den Messenger (letzterer wurde wohl nur von MSN nach Live umbenannt, um Live bekannter zu machen). Ich benutze aber auch keine Google-Tabellenkalkulation oder ähnliches, nicht nicht mal Google-Mail. Für die Synchronisation von Daten möchte ich eine stabile Server-Platform, die auf mein Kommando hört und schlimmstenfalls bei einem Provider meines Vertrauens steht. Ich möchte meine Daten auch sonst niemandem als FileShare bereitstellen, dafür habe ich entweder E-Mail (mit PGP, wenns vertraulich ist) oder einen passwort-geschützten Download-Bereich auf einer Website.
  • Ich entwickle seit dem Sommer 2003 mit (ASP).NET - eigentlich bin ich viel zu spät umgestiegen - und komme von Classic ASP (seit 1998) und HTML (seit 1995). Im Sommer 2004 haben wir in Karlsruhe die .NET Community Conference (NCC) veranstaltet. Die Themen waren damals unter anderem:
  • Sichere Webseiten mit ASP.NET
  • 3-Schichten-Architektur
  • Einfacher Datenbank-Zugriff im Code
  • Wiederverwendbarkeit von Code
  • Enterprise Library, damals noch als Application Blocks bekannt
    Wenn ich mir heute, fast genau 4 Jahre und 2,5 .NET-Framework-Releases später die Fragen der User in den Community-Foren wie glengamoi.com angucke, stelle ich fest, dass sich an der Problematik fast nichts geändert hat oder sich die Fragestellungen nur minimal verschoben haben.

Nachdem mich das Thema bereits häufiger beschäftigt hat, bin ich zu folgendem Resultat gelangt:

Microsoft verpasst bei jedem neuen Release von .NET und insbesondere Visual Studio die Chance, die Leute zu sauberer Softwareentwicklung zu erziehen. Stattdessen wird ab der ersten, der Öffentlichkeit vorzeigbaren Demo wieder die übliche "Mit-5-Klicks-ist-Deine-Website-Live"-Prozedur abgespielt, es werden neue Listen-Controls gezeigt, neue Datenbindungsmöglichkeiten usw..

Der begeisterte User/Entwickler geht nach genau diesem Schema vor, sobald er eine öffentliche Beta bekommen kann und baut seine Seite nach exakt den Demos, die er inzwischen überall findet. Doch binnen kürzester Zeit stößt er auf das eine oder andere Problem, das tiefergehendes Verständnis für (ASP).NET verlangt und er wendet sich vertrauensvoll an eine der zahlreichen Online-Communities zu .NET. Dort erlebt er nun über kurz oder lang ein eiskaltes Erwachen, denn er erfährt, dass

  • seine Seite im Jahre 2008 nach wie vor offen ist für SQL-Injection,
  • er bei einer anderen Architektur keinen Spaghetti-Code hätte,
  • er das Logging nicht hätte selbst implementieren müssen, da es das bereits fertig gibt
  • usw.
    Natürlich stellt sich nun die Frage, wie es besser wäre.

Imho sollte Microsoft davon abkommen, mit jedem Release noch mehr Features in irgendwelche Listen-Controls zu stecken und noch mehr Databinding-Varianten zu schaffen. Denn was benötigt jeder ASP.NET-Entwickler immer wieder? Sicher nicht irgendwelche Listen mit Edit-Funktionen, sondern individuell und standardkonform gestaltete Formulare, an die er im Idealfall seine eigenen Objekte binden kann - und davon bitte nicht nur eines, denn eine Auftragsübersicht hat viel mehr Objekte und ist natürlich wiederverwendbar.

  • Warum ist Microsoft erst jetzt im Ansatz dabei, ein MVC-Pattern für ASP.NET zu implementieren, obwohl dieses bereits mit ASP.NET 1.1 realisierbar war? Microsoft bot bereits damals den - zugegebenermaßen monströsen - User Interface Process Application Block an, der in die richtige Richtung zeigte - wie viele andere Dinge, die das Patterns and Practices Team geschaffen hat.
  • Warum schafft es Microsoft nicht, einen Designer für wiederverwendbare Custom-Controls - idealerweise als Views für MVP oder MVC-Pattern - zu entwickeln, die als eigene DLLs weitergegeben werden können?
  • Wieso versagt LINQ to SQL bei disconnected Szenarien nach einer so langen Entwicklungszeit trotzdem?
  • Wieso fließen die Arbeiten des Patterns and Practices Teams nicht stärker in die neuen Visual Studio Versionen ein?
  • Wozu gibt es ein Architecture Journal und ein MSDN-Magazine, in dem die Themen auf dem richtigen Level behandelt werden, wenn Visual Studio out-of-the-box zulässt, so ziemlich alles verkehrt zu machen, was in den beiden Magazinen gepredigt wird?
  • Wozu entwickelt Microsoft Unity, einen IoC/DI-Container und veröffentlicht Best Practices, wenn ich das mit meinem Spaghetti-Code gar nicht brauche?
  • Wozu soll ich mich an Prism orientieren, wenn ich meine WPF-Applikation mit Inline-Code "tunen" kann?
    Diese Liste liese sich noch beliebig weiterführen, aber ich denke, man versteht, worum es mir geht.

Ein Argument, das Microsoft sicher in den Raum wirft, ist die Lernkurve für Neueinsteiger und Umsteiger - doch sollten nicht gerade diese lernen, wie man es einfach und dennoch richtig machen kann?

Microsoft hat mit dem Team Foundation Server und Visual Studio Team System ein geniales Produkt für die professionelle Software-Entwicklung im Programm, das sich sicher noch besser verkaufen würde, wenn die Leute ein besseres Verständnis hätten für die Gründe, die hinter der Entwicklung von TFS u. VSTS standen: ins letzter Instanz ist es eine bessere Qualität beim Endprodukt, das damit oder dadurch ausgeliefert wird.

Warum investiert Microsoft nicht die - dank des an sich wirklich gelungenen Visual Studio 2008 - gewonnenen Zeitvorteile bei der Entwicklung gegenüber Ruby, Java oder Perl, um die Lösungen nicht nur schnell, sondern auch wirklich sauber zu implementieren - auch für einen Einsteiger.

Dass der Bedarf nach professionellen Ansätzen stärker denn je ist, zeigt die Entstehung der ALT.NET-Bewegung (die Dank Stefan Lieser inzwischen auch in Deutschland vertreten ist (warum nur in Gottes Namen bei Google ;-)) weltweit sowie die fast immer gleichen Fragen in den Foren, User Group Meetings, Konferenzen wie ASP-Konferenz, prio oder BASTA und zuletzt auch am ATE-Stand beim Launch von Visual Studio 2008, SQL Server 2008 und Windows Server 2008. Auch in Fachpublikationen wie dotnetpro, dotnet-Magazin oder ASP.NET Professional werden derartige Themen von den Lesern aufgesagt wie ein Schluck Wasser in der Sahara - warum nutzt Microsoft diese Chance nicht?

Imho sollte .NET, nachdem inzwischen sogar Teile des Quellcodes offenliegen, nicht nur von oben nach unten - d.h. ASP.NET-Team -> Scott Guthrie (sein Blog = Bibel für .NET-Neuerungen) -> ASP Insiders -> MVPs -> Trainer -> Anwender funktionieren, sondern es sollten auch tatsächlich Lösungsansätze aus der Praxis, sei es von Usern oder dem hauseigenen Patterns and Practices Team in (ASP).NET zurückfließen.

Dies erfordert natürlich auch von seiten der .NET-Community einen kriti(scher)en und fundiert(er)en Umgang mit .NET, anstatt (wie bisher), alles von Microsoft-Gegebene als das Maß der Dinge bei der Entwicklung anzusehen oder ansehen zu müssen...

So liebe Leser, jetzt seid Ihr dran ;-)

Wie und wo seht Ihr Euch, .NET und die Probleme, die es zu lösen gilt?