Follow my new blog

Montag, 12. Mai 2008

Microsoftdämmerung

image 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.

image 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.

imageDas 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.

image 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.

image 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!

10 Kommentare:

Anonym hat gesagt…

Prinzipiell stimme ich Dir zu, (siehe auch: http://blog.alexonasp.net/archive/2008/05/06/rant-ist-das-patterns-and-practices-team-nur-eine-alibi-mannschaft.aspx)

Ich denke allerdings, dass MS es nicht zwingend zur Microsoft-Dämmerung kommen lassen muß. Denn wenn MS schwindende Verkaufszahlen bemerkt, werden sie sicher gegensteuern, indem Sie mehr auf die geänderten Wünsche der User/Entwickler eingehen.
Dies ist - wie Dein Post gut aufzeigt - bisher schlicht nicht notwendig, weil die MS-Produkte, -Prototypen etc. leider momentan bei vielen das einzige ist, was sie im .NET-Umfeld wahrnehmen.

Wie in den Kommentaren zu meinem o.g. Post auch gut zu sehen ist, ist eine Verbesserung der Situation offenbar nur dann möglich, wenn die Entwickler selbst das Zepter in die Hand nehmen und sich auf die Suche nach Alternativen machen.

Insgesamt denke, ich dass Microsoft und .NET durch konstruktive Kritik (angeregt z.B. eben durch Produkte Dritter) nur besser werden kann.

Ralf Westphal - One Man Think Tank hat gesagt…

@Alex: Microsoft ist - wie IBM oder Siemens - so groß, dass es quasi unsinkbar ist. Man soll nie nie sagen, aber bei Microsoft oder auch Google fällt mir nicht so recht ein, was passieren könnte, dass es sie nicht mehr gibt. Oder bin ich zu Phantasielos? Was ist aus Dec oder Compaq geworden? Microsoft, IBM und Google gehören aber irgendwie einer anderen Klasse an.

Letztlich aber auch egal. Denn es geht mir ja nicht darum, dass ich mir Microsoft weg wünsche. Ich glaube vielmehr, dass Microsoft eine Größe hat, die für Microsoft selbst und damit für die Community drumherum kontraproduktiv ist.

Microsoft kann es sich erlauben, langsam zu sein. Das hat der späte Einstieg ins Internet gezeigt. Das hat der späte Einstieg in eine Managed Plattform gezeigt.

Wenn man als Entwickler aber auf Microsoft wartet, dann verschenkt man Chancen. Um die geht es mir. Als Entwickler kann man "überleben", wenn man mit Microsoft Bias geschlagen ist. Ist ja eine gutartige Krankheit ;-)

Aber Überleben ist etwas anderes als gut leben oder gewinnen.

Wenn Entscheidungen für O/R Mapper oder Unit Testing oder Kommunikationsinfrastruktur getroffen werden, dann wird niemandem gekündigt, der sich für Microsofts Portolio entscheidet. Das ist ne sichere Sache - und wenn´s schief geht, dann war Microsoft schuld.

Aber solches Sicherheitsdenken ist wieder etwas anderes als innovatives, flexibles, chancenergreifendes Denken.

Alle Marktteilnehmer lernen durch andere Marktteilnehmer. Microsoft lernt also natürlich auch. Die CTPs sind ein Beispiel.

Ob Microsoft lernt oder nicht, ist für die Entwickler recht uninteressant. Viel wichtiger ist, dass es in vielen, vielen Bereichen heute, hier und jetzt Alternativen zu Microsoft gibt. Das (!) sollten die Entwickler lernen und sich unabhängig machen von Microsoft.

Beispiel: Da ist ein Projekt, das nun auch eine ordentliche Codeorganisation und Produktion aufsetzen will. Sehr schön. Man entscheidet sich für... TFS. Beherrschen tut man den Boliden aber nicht. Es dauert also lange, bevor man wirklich die TFS-Ernte einfährt.

Die Alternativen wie Subversion+Tortoise, OnTime, Trac, FinalBuilder, CC.NET usw., die schlägt man in den Wind oder kennt sie nicht. Microsoft Bias! Mit Microsoft wird´s doch am besten funktionieren, oder?

Nun... vielleicht. Am Ende mal. Aber bis dahin ist der Weg lang. Warum nicht jetzt, hier und heute einen Schritt tun mit Subversion und Trac oder OnTime und FinalBuilder? Kostet weniger, ist einfacher zu installieren, ist einfacher zu verstehen.

Ist nur weniger integriert. Macht das aber was? Nein. Denn der Integrationsnutzen liegt bei TFS mangels Kenntnissen noch in weiter Zukunft.

Statt also sofort und billiger Erfahrungen in kleinen Schritten zu sammeln, erhofft man sich von Microsoft am Ende die Rettung.

Tragisch. Und eine Folge von Microsoft Bias.

-Ralf

PS: Nochmal, ums klar zu machen: Ich habe nichts gegen TFS im Allgemeinen. Ich bin nur dafür, "ohne Zorn und Eifer" Entscheidungen zwischen Alternativen zu treffen. Dafür muss ich aber die Alternativen kennen. Da es sie gibt, liegt der Schwarze Peter bei den Medien, die darüber zu wenig berichten. Naja, und auch jeder einzelne könnte sich natürlich etwas mehr ins Zeug legen, um über die Berichterstattung hinaus selbst auf Alternativen zu stoßen.

Anonym hat gesagt…

Cooles Posting, Ralf. Stimme Dir voll zu. Ich litt bis vor kurzem unter einem Java/J2EE/MDA-Bias. Dieselben Symptome, nur auf der anderen Seite.

Es fing schon ca. 1999 an, als ich Microsoft einmal auf einer CeBit nach O/R-Mapping fragte: "Haben Sie so etwas wie TopLink?". "Was ist denn das?" "Na, ein O/R-Mapper". "Wir haben ADO, das ist einfacher."
Da habe ich MS nach zehn Jahren Visual C++ und MFC und ATL den Rücken zugekehrt. Kein Hass, nur Ent-Täuschung.

In den letzten zwei Jahren hatte ich (vermittelt durch die Medien) den Eindruck, bei MS gäbe es noch kein Unit Testing und kein Refactoring. In Deinem Post lese ich von allerlei solchen Dingen, die es auch für die .Net-Plattform gibt. Vielleicht sollte ich mir das einmal intensiver ansehen? Allerdings ist es wirklich schwierig, mehr als eine Plattform im Architektenkopf zu haben.

A propos systemisches Denken: Das ist Trend, davon bin ich überzeugt. Es muss in die Softwareprojekte einziehen, die mir bisher immer noch viel zu sehr im Denkmodell "Rolle, Aktivität, Zeitpunkt, Ergebnis" verhaftet sind. Hast Du Lust, dass wir gemeinsam einen Artikel darüber schreiben?

Gruß,
Matthias

Ralf Westphal - One Man Think Tank hat gesagt…

@Matthias: Einen Bias gibt es natürlich für jede Plattform. Der ist auch bis zu einem gewissen Grad natürlich und unvermeidbar. Wichtig ist halt erstmal die Krankheitseinsicht ;-) Mit dem Willen zum Blick über den bisherigen Tellerrand Microsoft (oder Java&Co) ist dann schon viel gewonnen.

Natürlich gibt es auf der MS Plattform heute coole Tools/Technologien. Die solltest du dir anschauen. Manches war dann hier auch eher verfügbar als bei Java ;-) Aber das ist am Ende ein müßiger Vergleich. Wichtig ist, was da ist, und nicht, was wann wo wer als erster hatte.

Ob du allerdings wirklich fit auf zwei Plattformen sein kannst, bezweifle ich. Raten kann ich zu solcher Art Universalistentum nicht. Oberflächlich lässt sich das hinbekommen. Aber wirklich fundiert mit guter Praxiserfahrung? Weder glaub ich, dass das echt funktioniert, noch glaube ich, dass das nötig ist. Ich misstraue Leuten, die von sich behaupten, sie seien auf beiden Plattformen fit.

Als Architekt kannst du dir natürlich einen Überblick verschaffen. Die Detailarbeit und das Austesten von Grenzen hüben wie drüben, sollten dann aber Spezialisten der Plattformen übernehmen.

Systemisches Denken ist sicher unvermeidbar. Meine Architekturmethode heißt nicht umsonst "Systemorientierte Programmierung" ;-) Die Agilitätsbewegung hat das auch begriffen. Co-Lokation des Teams oder Pair Programming oder morgendliche Stand-up Meetings sind Ausdrücke dessen. Aber ich denke, das muss noch weiter gehen. Es muss sich auch noch mehr auf den Code beziehen. Aus systemisch muss noch mehr systematisch und systemorientiert werden.

Einen gemeinsamen Artikel kann ich mir allerdings nicht so gut vorstellen. Die Koord von Autoren ist immer schwierig. Aber warum schreibst du nicht einen Artikel - und ich schreib auch noch einen? Produktiver auch hier durch Entkopplung ;-) Kannst mir gern ne Email dazu mit deinen Ideen schreiben.

-Ralf

Rainer hat gesagt…

@Ralph: Ja den Bias kennen glaube ich viele. Ich bin auch dabei mir diverse Lösungen zum Bugtracking, Automatisierung, Codedokumentation, Produktion usw. anzusehen. SharePoint hat sich bei uns schon etabliert, bzw. ist dabei es zu tun. Hier werde ich also wenig einfluss haben, wenngleich mir das bisherige System nicht sonderlich gut gefällt. CC.NET habe ich mir bereits angesehen und es tut gute Dienste. Es ist recht einfach wie du sagst, gut beherrschbar und an seine eigenen Prozesse sehr gut anpassbar. Kann ich also nur jedem empfehlen. Wo ich dann doch etwas kritisch bin, sind deine Aussagen zu den Möglichkeiten. Wenn mir in meinem Unternehmen eine passende Lizenz des TFS zur Verfügung steht (z.B. durch MS-Partnerschaft), sprich ich keine weiteren Kosten für dieses Tool habe, warum sollte ich dann nicht diesen Schritt gehen und diese tolle Integration nutzen? Ok, da stellt sich die Frage, ob ich die Partnerschaft benötige, die ja auch nicht gerade billig ist. Viele Kunden wollen das aber. Da ist Überzeugungsarbeit zu leisten. Das kennen ich vom "Hörensagen" von Freunden, die im Consulting in der Javawelt aktiv sind. Die Integration ist für einen Softwareentwickler im Team ein großer Fortschritt, der viel mühselige Arbeit erleichtert. Die Integration macht das alles drum herum so viel einfacher, ich kann hiervonn ein Lied singen. Klar geht es ohne, es ist einfach der steinigere Weg, auch ich bin ihn bisher gegangen und werde mich nicht scheuen es weiterhin zu tun. Wenn ich als ausgebildetes "Spezialkommandomitglied in der Taskforce DevPro" bin, sollte alles kein Problem sein. Ich stimme dir zu, wenn es darum geht Alternativen zu sichten. Auch Spring.NET und AOP (mit PostSharp) werden mich in nächster Zeit wieder mehr beschäftigen. Ganz so ausgereift sind aber alle ansätze auch nicht. Das schöne jedoch ist die Offenheit des Quellcodes.

Gruß,
Rainer

P.S.: Was macht das Softwarezellenuniversum? Werde nochmal ein Review zu den Artikeln aus der dnp machen mit deinem aktuellen Artikel zusammen. Sehr gut, hat mir gefallen. Würde gerne noch mehr zu Architektur und Enterprise Patterns erfahren. Hab auch schon einige Quellen. Kannst du gute Literatur empfehlen? Gerne auch in Englisch

Ralf Westphal - One Man Think Tank hat gesagt…

@Rainer: Den Softwarezellen gehts gut. Sind jetzt in die "Systemorientierte Programmierung" eingegangen. Dazu gibt es immer wieder Darstellungen in der dotnetpro, aber keine allumfassende bisher.

Literaturempfehlungen? Wenige. Domain Driven Design von Evans, Enterprise Archi Patterns von Fowler, Object Design von Wirfs-Brock.

oo hat gesagt…

Schöne Zusammenstellung mit guten alten Bekannten - und besonders interessant, da wir grad eine komplett neue Architektur zusammenstellen, wo maximale Entkopplung und Modularität im Vordergrund stehen.

Dinge wie nServiceBus sind dabei interessante Ansätze, schiessen jedoch übers Ziel hinaus - wir suchen nach der Einfachheit und nicht nach einem voll flexiblen Teil. Was macht eigentlich XCoordination?

Ralf Westphal - One Man Think Tank hat gesagt…

@OO: XCoordination geht voran. In kleinen Schritten, aber voran. Das Interesse wächst. Wir haben inzw. einige early adopters. In der dotnetpro werde ich über das Konzept demnächst auch mal was schreiben.

Anonym hat gesagt…

Hi Ralf,
im großen und ganzen Stimme ich deinem Artikel zu, wobei ich zuletzt die Erfahrung gemacht habe, das es Microsoft Bias nahezu unheilbar ist, weil die Medikamente nich ausreichend zugänglich sind.

Vor kurzem durfte ich die Entscheidung zwischen der Java-Welt und der Microsoft-Welt treffen und mal einige Wochen nur mit Evaluierungen von verschiedenen Softwareprodukten verbringen. Aufgrund meiner Krankheitssymthome und der unbekannten Java-Welt, war es schon sehr zeitaufwendig, überhaupt die geeigneten Testkandidaten zu finden, zu installieren und abzuklären, ob das jeweiligs Produkt auch längerfristig verfügbar ist. Nun kam noch dazu, das beispielsweise zum erstellen des ersten Samples mit Hibernate verschiedene weitere Tools (z.B. ANT) installiert zusammengestöpselt werdeb müssen. Von Microsoftprodukten war ich es gewöhnt nach dem einheitlichen Ausführen eine Setups, ein Simple Sample mit wenigen Mausklicks ausführen zu können, das hat einfach was. Nun ist meine Microsoft Bias noch schlimmer geworden ;-)

Du hast auch geschrieben, das es von Microsoftprodukten meist mehr Literatur gibt. Dies läst sich wohl nicht so schnell ändern.

Aber es könnte sich etwas Ändern, wenn es ein qualitativ hochwertiges Internetportal für die Softwareauswahl gäbe. (Vielleicht gibt es das schon und ich kenne es nicht?) Hier müssten dann einfach alle Softwareprodukte in einer hierarchichen Struktur durchklickbar sein und mit sehr kompakten Informationen einen guten Zugang zu diesem Produkt bietet. Hierbei sind neben den rein technischen Informationen, auch Anworten zur stabilität, langzeitverfügbarkeit (bei Microsoft gibt es immer genügend Zeit, um auf die nachfolgertechnologie umzusteigen), Kosten und Risikobewertung für eine Entscheidungsfindung sehr wichtig.

Die Java-Welt hat meiner Ansicht nach den Höhepunkt überschritten und es gibt einfach zu viele und unüberschaubare Softwarepaketchen, da die Gesamtkoordination fehlt. Das darf bei der noch einigermaßen überschaubaren .NET-Welt einschl. Nicht-MS-Produkte nicht passieren, da ist so ein Portal unverzichtbar.

Gruß
Norbert

Ralf Westphal - One Man Think Tank hat gesagt…

@Norbert: Danke für deinen Kommentar, denn er hat ein Missverständnis aufgedeckt.

Mit MS Bias meinte ich nicht Blindheit für andere Plattformen. Andere Plattformen nicht (ständig) auf dem Zettel als Alternativen zu haben, halte ich für keine Krankheit. Das ist vielmehr normal und geht nicht (mehr) anders. Deine Schilderung macht das doch gut deutlich. Da helfen auch keine weiteren Infos. Es hilft nur die Erkenntnis, dass eben ein Wechsel nicht "einfach so" funktioniert. Das ist "Professorendenke", die meint, wenn man eines gelernt hat, könne man zügig auch anderes.

Der Umfang der Plattformen wird sich nicht mehr reduzieren. Im Gegenteil! Also hilft nur eines: Plattformfokussierung.

Wenn es den politischen Willen gibt, die Plattform zu wechseln, dann ist das natürlich ok. Aber das ist kein leichtes Unterfangen. Es braucht 2-3 Jahre, bis man wieder die alte Produktivität hat.

Mit MS Bias meinte ich, bei grundsätzlicher Entscheidung für die MS Plattform .NET eben nichts mehr außer MS-Angeboten zu sehen. Die gibt es aber, ohne dass ich mir einen Kulturschock einhandeln muss.

Also nicht .NET oder Java oder so, sondern bei Entscheidung für .NET die Frage ob Linq2Sql oder Vanatec OpenAccess oder Jabber mal statt WCF usw.