Es ist schon eine wundersame Welt. Also, in meinen Augen natürlich. Ich schreibe diesen Artikel ja auch, also kann es nur eine persönliche und subjektive Meinung sein. Aber immerhin, es ist eine Meinung, und das sogar ziemlich deutlich. Denn, ich habe den Artikel, die Kommentare und den Folge-Artikel von Golo zu seiner These “Räumliche Nähe wird überbewertet” gelesen. Das ich da anderer Meinung bin, habe ich ja schon gebloggt. Was also noch darauf rumreiten? Die Antwort ist einfach: Es ist wichtig, deswegen.

Kommunikation = Mitteilung + Wahrnehmung

Doch zunächst möchte ich in aller (nur notwendig langen) Kürze auf ein verwandtes Thema eingehen: Die Kommunikation. Besser gesagt, die zwischenmenschliche Kommunikation. Kommunikation ist eine schwierige und herausfordernde Kunst. Der eine sagt etwas, der andere versteht etwas. Ob es dann das ist, was der eine sagen wollte und der andere verstehen wollte, hängt von unheimlich vielen Faktoren und komplexen Sachverhalten ab. Doch zunächst gilt es festzuhalten: Kommunikation ist nicht nur Mitteilung, sondern auch Wahrnehmung. So geschehen auch bei der “Blog-Kommunikation” zwischen mir, Golo und dem “Publikum” (also auch Dir, lieber Leser).

Mit Golo’s Aussage fing es an: “Räumliche Nähe wird überbewertet“. Gut. Man könnte jetzt vieles wahrnehmen. Zum Beispiel könnte man wahrnehmen, dass Golo damit meint, dass ihm räumliche Nähe ein Graus ist. Oder man könnte wahrnehmen, dass Golo ein introvertierter, soziophober Alleingänger ist. Keines von dem ist der Fall. In meinen Augen ist derjenige, der so eine Wahrnehmung hat, einfach nicht aufgeschlossen und wohlwollend zu Golo’s Meinung. Dennoch – man könnte es sicherlich wahrnehmen.

Ich antwortete auf seine Aussage mit dem Artikel “Räumliche Nähe wird unterschätzt“. Gut. Man könnte jetzt vieles wahrnehmen. Zum Beispiel könnte man wahrnehmen, das ich damit “Verteilte Teams sind nicht erfolgreich” postuliere. Oder man könnte wahrnehmen, das ich ein opportunitisch-dogmatischer Agile-Fetischist bin. Keines von dem ist der Fall. In meinen Augen ist derjenige, der so eine Wahrnehmung hat, einfach nicht aufgeschlossen und wohlwollend zu meiner Meinung. Dennoch – man könnte es sicherlich wahrnehmen.

Aber jetzt mal Tacheles kommuniziert: Wer sollte denn so etwas annehmen? Ich finde so eine Wahrnehmung absurd. Ja, geradezu lächerlich. Demjenigen, der wirklich allen ernstes Golo nachsagen möchte, dass er Colocation als “schädlich” einstuft, oder aber mir den Vorwurf macht, ich würde “Colocation über Alles!” predigen, dem traue ich auch zu, dass er in “Satellite” keine Liebeshymne sieht, sondern es als öffentliche Drohgebärde einer Stalkerin zu ihrem Opfer interpretiert. Soviel dazu.

Die Mathematik der Meinung

Zurück zum Thema, der räumlichen Nähe. Ich bin nach wie vor der Meinung, dass räumliche Nähe unterschätzt wird. Unterschätzt in vielerlei Hinsicht. Ich gehe zunächst auf eine Perspektive ein, die auch schon angesprochen wurde: Effizienz und Produktivität. Golo schreibt in einem Kommentar treffend seine Motivation:

Golo: “…Es ging mir um die immer postulierte Allgemeingültig der Aussage “Colocation ist besser”. Zu zeigen, dass dem nicht so ist, genügt ein einziges Gegenbeispiel…”

Meine Meinung dazu: Ja, Richtig und Nein, Falsch. Das ist nicht logisch? Macht nichts. Ist trotzdem so.

Denn: Ja, es ist richtig, dass Golo nur ein Gegenbeispiel zeigen muss, um die Allgemeingültigkeit ad acta zu legen. Und: Nein, es ist falsch, denn meiner Meinung nach ist das gewählte methodische Werkzeug – nämlich die Anwendung der Aussagenlogik und deren Beweismethoden – völlig unangebracht. Bei allem Respekt gegenüber der Professionalität und Kompetenz von Golo bin ich etwas irritiert, das gerade der Berater für agile Methoden die Colocation nicht zu favorisieren scheint.

Doch die Motivation verstehe ich nur allzu gut – es wird öfters die “Colocation” als Heilsbringer dargestellt. Dem ist nicht immer so. Aber muss man deswegen so eine trockene, wissenschaftliche Herangehensweise wählen? Ich denke, dass es nicht unbedingt notwendig gewesen wäre, denn schließlich führt die Bool’sche Algebra hin zu einer totalitären “Schwarz-Weiss”-Wahrnehmung (wie oben geschildert). Dabei ist in Wahrheit nicht schwarz oder weiss schön, sondern alle Farben.

Leider wird für meinen Geschmack bei diesem Thema zu tief in die mathematisch-naturwissenschaftliche Logik-Kiste gegriffen. Logik & Mathematik sind mächtige Werkzeuge, die man oft und versatil einsetzen kann. Aber sie sind nicht die Weisheit für alle möglichen Systeme oder Lebenslagen. Ich meine, hier ist Logik alleine nicht das adequate Werkzeug. Vielmehr hilft meines Erarchtens hier der gesunde Menschenverstand mit dem unvergleichlichen Etwas, was uns Menschen auszeichnet: Emotion. Doch dazu komme ich gleich noch.

Handlungsfähigkeit, Produktivität und Effizienz

Fakt ist, dass Menschen, die an einem Ort, in einem Raum zusammenarbeiten, Ihre Arbeit in den meisten Fällen effizienter, effektiver und produktiver gestalten und erledigen. Abseits von Agilität und unabhängig von der eingesetzten agilen Managementmethode stellt man fest: In sehr vielen Fällen ist ein “Warroom” oder “Teamroom” für eine erfolgreichere Gestaltung des Vorhabens nicht nur hilfreich, sondern mit ausschlaggebend. Darüber hinaus entwickelt sich ein deutlich zügigerer Durchlauf des Teams durch die Tuckman-Phasen. Mit der Zeit entwicklelt man auch ein viel besseres Verständnis zu den Aufgaben anderer und vermag auch, den anderen in brenzlichen Situationen zu helfen. Und manchmal ist man auch ganz glücklich, wenn einem selbst ein wenig unter die Arme gegriffen wird.

Es gibt dabei meiner Meinung nach aber noch einen weiteren wichtigen Aspekt. Es ist die Teamaufstellung. Es ist eines der Dinge, die bei der Diskussion für mein Empfinden viel zu wenig herausgearbeitet wurde. Oder besser auf Deutsch gesagt: es wurde einfach ignoriert. Schade. Denn ein agiles Team ist nur dann ein agiles Team, wenn es interdisziplinär (bzw. “cross-functional”) ist. Warum das so ist, habe ich ja schon geschildert. Der Effekt, der dabei entsteht, ist eine wesentlich effizientere Kommunikation zwischen den einzelnen Domänen- und Fach-Experten. Darüber hinaus werden intuitiv und äußerst effizient gemeinsame Schnittstellen und eine Ubiquitous Language entwickelt.

Es gibt noch eine Menge anderer Dinge, die ein interdisziplinäre und lokale Teamaufstellung zu einer Präferenz zu anderen Teamstrategien macht. Doch der kausale Kern eines agilen Teams ist und bleibt geschäftsgetrieben. Ein agiles Team ist “im Kern” nur interdisziplinär, weil es der einzige Weg ist, ein Feature als Ganzes, also integer und abgeschlossen, umzusetzen. Das es nebenbei diese Aufgabe auch noch effektiver löst, als andere Teamaufstellungen, ist die “Sahne” auf dem Kuchen.

Mi Kasa Es Su Kasa

Ein weiterhin von Golo und anderen Kommentatoren kritisch beäugtes Merkmal von “Colocation” ist die “Minderung der Produktivität durch Störungen”. Diese Argumentation ist für Agilisten nichts Neues. In meinen Augen ein Indiz für Ängste. Man befürchtet, dass man durch “den Lärm” und “die Unterhaltungen” im Raum nicht mehr konzentriert arbeiten kann, sich jeder die Kopfhörer aufsetzt und in seine Welt entschwindet. Man befürchtet, dass man sich nicht mehr in seinem eigenen kreativen Mikrokosmos nicht mehr wohlfühlen kann. Man befürchtet, beobachtet zu werden. Man befürchtet, sich einfach nicht mehr in die Arbeit “gehen lassen” oder “eintauchen” zu können. Das sind verständliche Ängste. Besonders dann, wenn man noch nie oder erst selten mit agilen Teams – oder als Teil eines agilen Teams gearbeitet hat. Ich kann das nachvollziehen.

Doch ich kann es nicht nachvollziehen, dass manche – wohl genährt durch diese Befürchtungen – behaupten, dass es “sowieso nicht besser wäre”, oder für die einzelne Persönlichkeit und den einzelnen Charakter ungeeignet sei. Noch dazu ohne es einmal ausprobiert zu haben. In meinen Augen ist das eine lapidare und profane Argumentation. Viel zu oft gewinne ich dadurch den Eindruck, das dieser Schlag von Entwicklern ein wenig zu oft an sich selbst denkt als an andere Teammitgleider und die gemeinsame Sache.

So sind z.B. Designer und UX-Experten wesentlich intensiver mit kreativer Schaffung konfrontiert und damit auch deutlicher abhängig von ein Umfeld, in dem die “Kreativität keimen und reifen” kann. Auch Produkt Manager sind oft mit hochkonzentrierten und komplexen Denkprozessen beschäftigt, wenn es z.B. um die Entwicklung von neuen Features eines Produktes geht. Was ich damit sagen will: Jeder ist ein Mensch, nicht nur die “Coder”. Wer wünscht sich nicht gerne sein eigenes “Arbeitsreich”? Doch auch wenn man es hätte, in den meisten Fällen wäre es für die gemeinsame Sache eben nicht zielführend, das jeder sein Reich hat und sein eigenes Ding auf seine eigene Art und Weise macht.

Interessanterweise sind es aus meiner Erfahrung gerade diejenigen, die mehrheitlich Konzentrations- oder Kreativitäts-Aufgaben erledigen, am wenigsten Probleme mit der Zusammenstellung interdisziplinärer Teams in einen Raum haben. Im Gegenteil. Sie fühlen sich inspiriert und freuen sich, dass ihre Arbeit auch gesehen und bewertet werden kann. Ein guter & agiler Web-Designer z.B. freut sich über jedes frühe Feedback – von jedem. Natürlich braucht man auch seine Ruhe- und Schaffungsphasen. Jeder braucht das.

Das ist im Übrigen eines der ersten Dinge, die ein agiles Team auch lernt und gestaltet: Ruhephasen – Bibliotheksmodus – Silentio. Ein weiteres, hilfreiches Merkmal solcher “hyperproduktiven Arbeitsumgebungen” sind Fluchtpunkte. Also Ruheinseln, in denen man sich zurückziehen kann. Für Persönliches oder Privates. Oder einfach nur so, zum ausruhen. Powernap. Etwas lesen. Am Flipper eine Runde zocken und den Kopf etwas frei kriegen. Auftanken.

Ich sage nicht, das all das, was ich gerade erwähnt habe, nicht auch mit verteilten Teammitgliedern möglich wäre. Es ist auch machbar. Die Profi’s Golo & Peter sind ein gutes Beispiel dafür. Aber es ist meiner Meinung in sehr vielen Fällen ungleich schwieriger, deutlich fragiler und auch minder effizient. Mit Colocation funktioniert es natürlich auch nicht immer – aber dafür deutlich öfter, einfacher und produktiver.

Emotion. Hautnah.

Zurück zu dieser einen “ungreifbaren” Sache, die mit agilen Teams an einem gemeinsamen Ort besonders hervorstechend ist. Die Emotion. Emotion ist etwas so wichtiges und schönes. Auch für Entwickler und Nerds. Man regt sich über den langsamen SATA-Treiber auf. Man installiert gespannt die neuesten Plugin’s für Visual Studio während man sich mit dem Käsebrötchen vollkrümelt. Man lacht sich über den 3. roten Build des Tages kaputt, weil es wieder einmal ein Leichtsinnsfehler war.

Doch Emotion ist nicht nur für einen selbst wichtig. Emotion ist auch für andere wichtig. Die Sprache ist nur ein Teil der Kommunikation. Manche Streiten sich darüber, ob nur 7% unserer gesamten Kommunikation verbal ist. Fakt ist, Sprache ist nicht alles. Den Satz “Ich verstehe.” von einer langfährigen, erfahrenen Web-Designerin zu hören – flüsternd, mit glasigen Augen und zittrigen, schweißgebadeten Händen, die sie vergebens versucht hinter ihrer großen Pop-Art-Teetasse zu verstecken – oder aber “Ich verstehe.” mit resoluter Stimme wahrzunehmen – gefolgt von einer gekonnten Seitwärtsdrehung, die ihre zum Pferdeschwanz gebundenen Haare durch die rapide Rotationskraft zu einem Duftkatalysator ihres Luxusparfums entarten lässt und mit der Registrierung ihrer kalten Schulter abrupt endet. Ein und das selbe Wort – doch zwei Nachrichten, die gegensätzlicher kaum sein könnten. Natürlich gibt es noch tausende von andere Bedeutungen des Satzes “Ich verstehe“, aber ich denke Du verstehst, was ich meine. ;)

Für einige mag das jetzt zu weich, unlogisch, konstruiert oder unwissenschaftlich sein. Aber das ist mir egal. Denn das ist es, was ich am Anfang dieses Artikels mit “es ist wichtig” gemeint habe und was ich zum Ausdruck bringen will: Agile Teams, die gemeinsam an einem Ort arbeiten sind sicherlich nicht perfekt. Aber sie sind in der deutlichen Vielzahl der Fälle produktiver, effektiver, handlungsfähiger, änderungswilliger, offener, respektvoller und: emotionaler.

Das Ergebnis ist eine gewisse Energie, eine gewisse Magie, die bei agilen Teams mit Colocation öfter und schneller entsteht. In dem letzten Slide meines Enthusiasmus-Vortrags über Scrum beim Webmontag in München sieht man eine Band im Sonnenuntergang zusammenspielen. Das spiegelt die Energie & Magie ein wenig wider: die Emergenz des Teams. Das Ganze ist mehr als die Summer der einzelnen Teile.

Und damit dieses ach so kindische “aber du sagt das ist toll und alles andere ist blöd”-Fingerpointing nach diesem Artikel hoffentlich keinen Nährboden findet, nochmal ein klarer Disclaimer: Ich habe die Weisheit nicht gepachtet. Ich bin kein Klugscheißer und Besserwisser, und ich will es auch nicht sein. Aber ich habe eine Meinung. Ob sie Dir gefällt, lieber Leser, musst Du schon selbst wissen.

Für mich ist klar: wer wirklich agile Software-Entwicklung betreiben möchte, der wird versuchen, ein Team an einem gemeinsamen Ort arbeiten zu lassen. Wenn es nicht möglich ist, dann eben mit Hilfsmitteln verteilt. Alles andere ist in meinen Augen weder agil, noch fortschrittlich, noch wirklich produktiv. Ob das für Dich, lieber Leser, auch so ist, musst Du schon selbst wissen.

Ich bevorzuge es, wenn ich meinem Kollegen auf die Schulter klopfen kann, wenn er einen genialen Integrationstest geschrieben hat. Oder dem Web-Designer in sein kritisches Gesicht zu blicken, wenn er wieder einmal den Usability-Prototyp der UX-Designerin begutachtet und währenddessen sich die Komplementärfarben im Pantone-Fächer zurechtsucht. Es ist für mich eine Ehrensache, dem gestressten Produktmanager beim sortieren und formulieren der neuen User Stories zu helfen, weil er in einer Stunde ein wichtiges Meeting mit dem Marketing hat. Und: es baut mich auf, wenn meine Teammitglieder mich anlächeln, weil ich ein Feature mit einem Kollegen fertiggestellt habe und wir uns nach dem grünen Build in den Armen liegen, als wäre der FC Bayern gerade Championsleague-Sieger geworden.

Ich bevorzuge agile Teams an einem Fleck, an einem Ort, in einem Raum.
Gemeinsam für die gemeinsame Sache.
Räumliche Nähe wird unterschätzt.

Thomas stellt zur Debatte, ob man aus Repository-Methoden ab und zu auch mal null zurückgeben darf/kann/soll. So z.B. bei so einer Methode:

User GetUserByName(string name);

Mache das Unmögliche möglich?!?

Einige Leute finden das garnicht besonders gut. Sie bevorzugen lieber soetwas wie einen “nicht-existenten” User zurückzugeben. Also eine Instanz einer Klasse, die eigentlich garnicht möglich wäre (weil sie ja die nicht exsistierende Instanz darstellt). Programmtechnisch ist das sicherlich recht einfach lösbar – oftmals mit einer statischen Property, die sich wiederum eines privaten Konstruktors bedient. In dem obigen Beispiel könnte eine derartige Implementierung ungefähr so aussehen:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    return User.NotExistent;

  //user laden und zurückgeben
}

Eine zweite, nicht minder bevorzugte Alternative zur Rückgabe von NULL ist die beliebte Exception. Falls also kein Benutzer unter dem angefragten Namen existieren sollte, dann soll eine Ausnahme signalisiert werden. Ganz einfach implementiert:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    throw new UserNotFoundException(name);

  // user laden und zurückgeben
}

Beides sind sicherlich mögliche und sogar gute Alternativen zu der Implementierungsvariante, die Thomas zur Diskussion gestellt hat:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    return null;

  // user laden und zurückgeben
}

Um es kurz zu fassen: Alle drei Varianten sind möglich, alle drei Varianten sind gut, alle drei Varianten sind schlecht. Es kommt auf den Anwendungsfall an. Die beliebte “It-Depends”-Weisheit streckt das Thema mit geballter Kraft nieder. Dennoch ist es eine Untersuchung wert, denn ungewöhnlicherweise wird die NULL-Variante kategorisch als falsch und “böse” bewertet.

Nullbivalenz

NULL ist ein besonderer Wert. Er ist der Wert, der eigentlich nicht zugewiesen werden kann. Genauer genommen ist er kein Wert, sondern nichts anderes als die knapp in vier Buchstaben formulierte Aussage “Ein für eine bestimmte Werteklasse belegter Ort wurde mit keinem Wert belegt”. Ergo: Null ist kein Wert. Ja, aber ist das denn nicht genau das, was GetUserByName ausdrücken und zurückgeben muss, wenn es keinen Benutzer für den gegebenen Namen findet?

Schaut man sich die erste Alternative zu NULL an (also das User.NonExistent-Konstrukt), dann kann man sagen: Joa, ok – ist aber das Gleiche. User.NonExistent ist sicherlich expliziter als NULL. NULL ist aber schon da und genau für solche Dinge gedacht. Die Aufgabe von NULL ist ja genau die, keinen Wert darzustellen.

Und wie sieht es mit Alternative Zwei – der UserNotFoundException aus? Die Excpetion ist auch explizit. Mehr noch, die Exception ist flexibel und rigoros gleichermaßen. Flexibel, weil sie jederzeit aus dem Nichts auftauchen kann. Rigoros, weil sie eine Fülle von Informationen über den Kontext sammeln und mitgeben kann. Die Exception sagt hier klar und deutlich: “Es gibt keinen Wert, weil der Benutzer {name} nicht gefunden wurde.”. Scheinbar ein Vorteil gegenüber den anderen Varianten. Im Ergebnis ist es jedoch nicht wesentlich von den anderen Herangehensweisen unterscheidbar.

Null Sicherheit

Nun, offensichtlich ist die sprechendere Variante der Exception vorteilhaft und damit dem NULL vorzuziehen. Doch beim zweiten Blick entpuppt sich der Vorteil als nicht so deutlich als zunächst vermutet. Denn in der Praxis kann sich die “unklare” und “unexplizite” Art von NULL wieder als erwünscht erweisen.

So muss man bei Exceptions, um den Mehrwert zu kennen, auch deren Typ genau kennen. Man muss also Wissen, das es sich um eine UserNotFoundException handelt. Erst dann kann man auch erfahren, welcher ominöse Benutzer unauffindbar ist. Das kann durchaus problematisch werden, wenn man also im höheren Callstack wissen muss, um welche Exception es geht, denn schliesslich schafft man sich dadurch eine Abhängigkeit auf den niedrigeren Code.

Null ist also eine unsichere, uninformative, aber immer verfügbare und unabhängige Variante, dem Aufrufer zu sagen: “Es gibt keinen Wert für das, was Du von mir verlangst”. Wenn man sich mit der Anwendung von NULL jahrelang auseinandergetzt hat und auch ein wenig die ungeliebten Interna von Speichermanagement & Datenstrukturen hineinblickt, dann wird NULL schnell zu einer praktikablen Lösung für schwierige Situationen.

Doch vor Allem bei NULL stellt man immer wieder fest: praktikabel und elegant sind zwei verschiedene paar Schuhe. Denn NULL ist genauso nichtssagend wie vielseitig. NULL zwingt den Aufrufer zum Abwägen: Soll ich das Ergebnis gleich auswerten oder lieber überprüfen? Ein wunderbares Beispiel dafür ist sicherlich der “if (x != null)”-Check – die Null-Prüfung. Das wird vor Allem dann zum Problem, wenn man mit (gewollt oder ungewollt) unbekannten Komponenten arbeitet. Im Interface oder in der Typsignatur steht es jedenfalls sehr selten erkennbar drin, ob nun in Einzelfällen NULL zurückgeliefert wird oder nicht.

Null ist nicht gleich Null

Für mich gibt es beim Umgang und bei der Anwendung von Null keine Faustregel. Ich gebe in einigen Methoden NULL zurück. Meistens genau dann, wenn ich wirklich damit ausdrücken möchte, dass etwas katastrophales passiert ist. Ich finde es sehr schwerwiegend, NULL als Zuweisung oder Rückgabe stehen zu lassen – aber ich mache es manchmal ganz bewusst. In einer Anwendung, in der ich z.B. Benutzer über einen Authentifizierungsdienst identifizieren muss, bevor ich überhaupt etwas anderes machen kann, kann die folgende Signatur NULL zurückliefern:

interface IAuthenticationService
{
  Account SignIn(string user, string password);
}

Es kann alles mögliche passiert sein – keine Verbindung zum Server, falscher Server, Verbindungsfehler, Connection Timouts, Benutzer nicht gefunden, Benutzer gesperrt, Passwort abgelaufen, falsches Passwort – all dies würde ich versuchen über Exceptions oder Return-Codes zu erledigen. Die meisten der Exceptions gibt es ja schon frei Haus vom Framework. Aber für das mich Unbekannte und Unerwartete gibt es immer noch eine Rückgabe, und die heisst NULL.

Null-Summen-Spiel

Generell kann ich für mich nur sagen, dass ich gelernt habe mit NULL sehr vorsichtig umzugehen. Ich vermeide es so gut wie möglich. Exceptions sind ein gutes Mittel – allerdings setze ich sie auch nicht sehr oft ein. Die Bürde der Abhängigkeit ist schon da – obwohl es natürlich in der Contract-Assembly definiert ist. Bei Repositories habe ich (fast) immer Ergebnisse die nicht NULL liefern. Andererseits setze ich NULL als Rückgabe auch öfter ein, wenn ich nur eine “schwere” Ausnahme in meinem Code feststelle.

Im obigen Beispiel hätte ich wohl NULL als Rückgabe toleriert, vor Allem, wenn ich davon ausgehen kann, dass es oft – oder sehr oft – dazu kommen kann und diese Tatsache ein schwerwiegendes Problem darstellt. Ein schönes Beispiel sind immer wieder die Brute-Force und DOS-Attacken auf Webportale.

Ich hätte wahrscheinlich nicht NULL zurückgegeben, sondern eine Exception ausgelöst, wenn ich das Ganze als wiederverwendbare, allgemeine Kompontente entwickeln würde.

So oder so – beides ist machbar und beides hat seine Berechtigung. Klar und deutlich soll aber abschließend erwähnt sein: NULL zu vermeiden ist eine gute Sache. Es macht den Code expliziter, offensichtlicher und lesbarer.

Zur Datenerfassung verwendet es im Hintergrund Microsoft Netmon, bereitet diese auf und stellt sie übersichtlich graphisch dar. Ein weiteres nettes Feature ist die Bewertung der Daten durch den Analyzer auf Basis verschiedener Aspekte, wie z.B. Bandbreiten-Effizienz, Expiration-Dates, Image clustering oder TTFB. Hilft meiner Meinung nach zur schnellen Analyse.

Session 1: Steve Teixeira über Multi-Core Software-Entwicklung

Steve Teixeira ist Program Manager beim Parallel Developler Tools / Visual Studio Team in Redmond und hatte in seiner Session neben der grundlegenden Einführung der neuen API für Multithreading auch einige Neuigkeiten über die nächste Visual Studio Version zu berichten. Doch alles der Reihe nach. Zunächst einmal schilderte Steve, wieso man sich eigentlich Gedanken über Parallele Ausführung von Code machen sollte. Der Grund ist natürlich bei der Hardware-Entwicklung vergraben, denn mittlerweile gelangt man an die Leistungsgrenzen im CPU-Design mit einem Kern. Der Hauptgrund ist die inzwischen fast unkontrollierbare Wärmeleistung, die die Chips von sich geben. Der Trend ist zu Multi-Core-CPU’s ist eindeutig auch im Alltag angekommen.

Das wiederum macht es erforderlich, die Software auf die neuen Gegebenheiten anzupassen. Steve zeigte ein schönes Beispiel mit Hilfe von PLINQ um die Unterschiede zwischen sequentiellem und parallelisiertem Code deutlich zu machen. Was heißt das für den “Alltags-Entwickler”, wie ich es z.B. bin? Nun, zunächst einmal bedeutet es eine Schärfung der Coder-Sinne auf das Thema Performance. Ich fühle mich zwar in diesem Thema schon heute gut aufgehoben, aber es dürfen ruhig noch ein wenig mehr Details sein.

Unterstützt wird dies im Besonderen durch das neue Visual Studio 2010. Es kommt mit neuen Tools wie Performance und Concurrency Profilern, die deutlich, graphisch anschaulich zeigen, wieviel Zeit die Software für bestimmte Aktionen verbraucht und mit welchen Ressourcen diese Leistung erreicht wurde. Auffällig dabei sind auch die Optionen, die das neue Performance-Tool bietet: CPU-basiertes Sampling, komplette Instrumentation, also Analyse aller Zeiten und Zyklen von Methodenaufrufen und das schon eben erwähnte Concurrency Profiling, mit dem man in der Lage ist zu erkennen, wie die Threads mit den Aufgaben ausgelastet sind.

Eine “Performance Debugging Suite” also, die im neuen Visual Studio verankert sein wird. Voraussetzung ist jedoch die Installation auf Windows Vista oder Windows 2008, da die Monitoring-Tools intern eng mit der seit Vista erweiterten Windows Eventing API (ETW) zusammenarbeiten.

Für so passionierte .NET-Entwickler wie mich ist die Verwendung der neuen API einfacher als erwartet. So lassen sich z.B. LINQ-Abfragen elegant mit dem “Anhängsel” .AsParallel() parallelisieren. Mindestens genauso einfach lassen sich auch Codebestandteile für die Parallel-Ausführung trimmen. Eine einfache for-Schleife ist mit Parallel.For() im Nu für die Parallelisierung umgesetzt. Die Nebeneinanderausführung von separaten Codeteilen mit Parallel.Invoke() ist zügig definiert und intuitiv. All diese Dinge sind fest im neuen .NET Framework 4.0 verankert. Interessant in diesem Zusammenhang ist, das Steve explizit auf deutliche Verbesserungen “unter der Haube” hingewiesen hat. So ist z.B. die ThreadPool-Klasse intern mit neuen Strategien wie dem Work Stealing ausgestattet worden, um die Verteilung der Aufgaben in Multi-Core Umgebungen zu optimieren.

Ein helles Ohr hatte ich auch bei den vielen kleinen Anekdoten und Anmerkungen von Steve. So ging er flüchtig auf die Entwicklung von Visual Studio ein und verriet, das der Visual Studio Code mehrheitlich in C++ und C# geschrieben ist und derzeit mehr als 45 Millionen Codezeilen umfasst. Interessant ist auch die Tatsache, dass das Visual Studio Team bei der Entwicklung von neuen Komponenten und UI verstärkt WPF im Einsatz hat. Steve begründet das mit der schlichten Tatsache, das WPF schnell genug ist und eine wesentlich effizientere UI-Entwicklung ermögliche als mit der klassischen GDI.

Fazit: Ein absolutes Highlight – Visual Studio 2010 in Aktion und Insider-Wissen. VS10, Parallels & .NET 4.0, ich warte auf euch…

Session 2: Holger Schwichtenberg und AJAX Services

AJAX ist nicht nur in aller Munde sondern heutzutage schon fast auf jeder Website in irgendeiner Form im Einsatz. Das man AJAX auch in ASP.NET einsetzen kann, ist spätestens nach dem .NET Framework 3.5 keine besondere Neuigkeit mehr. So auch der Inhalt der Session von Holger. Er machte einen knapp einstündigen Rundflug über die Möglichkeiten des AJAX-Einsatzes in ASP.NET, darunter das berüchtigte UpdatePanel (aka. AJAX für Arme), das AJAX Control Toolkit (aka. Atlas) und die kleinen Tools, die mit den ADO.NET Data Services einhergehen.

Auf AJAX-Spezifische News für .NET 4.0, den JQuery-Support mit ASP.NET 4.0 oder Visual Studio 2010 ging Holger garnicht oder nur am Rande mit einem Keyword aus einem Slide ein. Schade, aber aus meiner Sicht eine sehr schwache und fachlich “äußerst überschaubare” Session. Besonders die Argumentationen von Holger für so manche Technologie sind in meinen Augen etwas zu oberflächlich. So geschehen bei einer Frage eines Zuhörers:

Zuhörer: Bei den ADO.NET Data Services verzichten Sie auf eine gewohnte 3 bzw. N-Tier Architektur. Dies wurde lange als “Best Practice” vermittelt und nun wird das mißachtet. Was meinen Sie?

Schwichtenberg: Nun, ich sage Ihnen ja nicht, das eine N-Tier Architektur nicht empfehlenswert ist. Aber – mit ADO.NET Data Services ist der Betrachtungswinkel ein anderer. Während “klassische” Web Services nur die Daten und Funktionen herausgeben, die wirklich benötigt werden – also praktisch die Daten schon serverseitig Filtern – wird bei den ADO.NET Data Services zunächst der gesamte Datenbestand im Web Service angeboten. Der Client kann nun über die REST-Query entscheiden, was er konkret benötigt. Aus meiner Sicht ist diese Herangehensweise ein Produktivitätsgewinn.

Na, das ist ja eine feine Aussage! Sichereitsbedenken scheint Holger nicht zu haben, wenn er alle Daten frei verfügbar macht. Des Weiteren ist die Konstellation AJAX + ADO.NET Data Services + Entity Framework sehr wohl eine “Tiered Architecture”, Das Entity Framework löst den klassischen Data Layer ab. Die Data Servies können als “Business Layer” durchgehen (man kann ja selbst noch einiges dazu entwickeln und der Zweck eines “Data Providers” kann in meinen Augen auch als “Business” definiert werden). Zu guter letzt ist AJAX bzw. die Website die UI bzw. das Frontend. Naja, vielleicht habe ich es auch nicht richtig kapiert, was Holger damit gemeint hat.

Fazit: Eine der schwächeren Sessions, die fachliche Tiefe und vor Allem Neuigkeiten bzw. Best Practices vermissen ließ.

Session 3: Dariusz quatscht hessisch, und zwar “Windoos Äschär”

Der Name ist Programm: Dariusz wagt sich in die neue blaue Windows-Welt: “Windoos Äschär” – so meint er könnte man es zumindest versuchen, die neue Service-Familie auszusprechen. In wohl bekannter Manier stieg er fröhlich in die Thematik mit einem Überblick ein.

Da wären zunächst die .NET Services “Access Control”, “Service Bus” und “Workflow”. Der Access Control Dienst so etwas vergleichbares wie ein etwas besserer, Claims-basierter Single-Sign-On Service mit Authorisierungsmanagement. Über eine Claims-Challenge können sich Nutzer und Dienste gleichermaßen authentifizieren. Dabei kann man aus der gewohnten Variabilität der Authentifizierungsart wählen – ob nun UserNamePassword, Zertifikate, Windows Live ID – Claims bleibt Claims. Der Service Bus ist der aus größeren Unternehmen bekannte ESB portiert auf die “Cloud”. Mittelfristig soll mit dem Service Bus eine “orchestrierte” Gemeinde von Diensten zur Verfügung gestellt werden. Das Pattern ist jedenfalls nicht neu. Der dritte im Bunde ist der Workflow Dienst. Basierend auf der WF kann er als “Schaltzentrale” verwendet werden. Momentan ist dieser Baustein noch sehr rudimentär, soll aber weiter ausgebaut werden.

Eine weitere Service-Gruppe ist die “SDS” – die SQL Data Services. Gleich zu Beginn klärt Dariusz hier den Unterschied zwischen “Azure Storage” und den “echten” SQL Diensten. Während die Storage eher eine “einfache, sqlfähige Datenablage” ist, sollen die SDS mittel- bis langfristig wesentlich mehr Features anbieten wie z.B. Reporting, Data Mining oder ETL Dienste. Gewöhnungsbedürftig bei den SDS ist die Organisation der Daten: Man hat nicht mehr die klassischen, relationalen SCHEMA TABLE ROW Strukturen. Statt dessen befinden sich die Daten in sog. “Containern” (vergleichbar mit Datenbanken oder Schemata). Die Daten wiederum sind als “Entities” strukturiert. Eine Entity hat mindestens einen Typ (also den Entity-Namen), eine EntityID und den EntityKind, welche Aussage über die Art oder Klasse der Datenstruktur geben soll. Weitere Felder sind frei definierbar. Die Feldtypen beschränken sich derzeit nur auf einfache Datentypen.

Auf weitere Dienst-Gruppen ist Dariusz nicht eingegangen – wie sollte er auch – er hatte während der Session mit anderen Problemen zu kämpfen. Jede zweite Demo ging nicht oder brach mit irgendwelchen Exceptions ab. Tja, er musste selbst zugeben, das “Äschär” noch nicht ganz fertig ist und an der einen oder anderen Stelle die notwendige Reife für den produktiven Einsatz vermissen ließ.

Der erste Eindruck den Windows Azure und die “SOA-Diensten” hinterlassen ist das Interesse an Neuem mit einer großen Portion Skepsis. Auch wenn irgendwann einmal Azure stabil und schnell wird bleibt abzuwarten, ob die Plattform attraktiv und intuitiv genug ist, um echte Anwendungen darauf laufen zu lassen.

Fazit: Mal sehen was daraus wird!

Session 4: Dirk Primbs schreibt effizienten Code in C# 3.0

Dirk ist eines der bekanntesten Gesichter auf Konferenzen – kein Wunder, schließlich ist er seines Zeichens Developer Evangelist bei Microsoft. Die heutige Session hatte die Überschrift “Effizienter Code in C# 3.0″ – das hörte sich vielversprechend an. Also dachte ich mir, wenn ich schon nicht in die Session von Berndt gehen kann (er war leider nicht anwesend und wurde durch Dariusz vertreten), dann höre ich mir mal an, was Dirk mir über Effizienz mit C# 3.0 zu erzählen hat.

Leider war nicht ganz in dem Paket drin was draufstand. Dirk verbrachte über die Hälfte der Zeit damit, die Geschichte von .NET und C# zu erzählen. Angefangen bei C# 1.0, über C# 2.0 bis zum aktuellen C# 3.0. Die aktuelle 3.0-Version kam dabei für meine Begriffe viel zu kurz. Dirk vermittelte in seiner Retrospektive über C# 2.0 sehr gut, was Generics, Anonymous Methods und Discrete Property Accessors sind. Doch besonders prickelnd war es nicht gerade, mittlerweile gängige Konstrukte nochmals vorgekaut zu bekommen. Mit C# 3.0 hatte das wenig zu tun, und mit effizientem Code auch nicht.

Wahrscheinlich habe ich mir unter dem Titel “Effizienz” etwas anderes vorgestellt als Dirk. Er ging auf Syntax und “eleganten” Code ein, wo ich eher Effizienz-Vergleiche zwischen konkrekten und anonymen Typen erwartet hätte. Dennoch war es nicht langweilig – wer Dirk schon öfter erleben durfte, der weiß warum.

Es blieb am Ende doch noch eine gute Viertelstunde übrig, um auf neue Sprachkonstrukte und Features von C# 3.0 einzugehen. Type Inference und das var Keyword, Object Initializer und Automatic Properties. Wie zu erwarten war, wurde die Verwendung des var Keywords “angeregt” diskutiert. Ich hatte mich in einem Post ja schon über den Sinn und Zweck von var geäußert. Äußerst bedauernswert fand ich allerdings, das kein Sterbenswörtchen über C# 4.0, die DLR, das dynamic keyword oder Duck Typing verloren wurde. Zumindest ein Ausblick und ein kurzer Rundflug wäre schön gewesen.

Fazit: Eine Mischung aus “Basics Workshop”, Human FxCop und OpenSpace Talk – locker, bekömmlich, bekannt.

Soviel zum ersten Tag. Mal sehen, was der zweite bringt… :-)

Meine Session-Auswahl für den ersten Tag:

• Bringing out the best in Multicore Systems, Steve Teixeira
• AJAX-Live im Services Zeitalter, Holger Schwichtenberg
• Software-Entwicklung mit Windows Azure, Dariusz Parys
• Parallel Extensions für Microsoft .NET, Bernd Marquardt

Mal sehen, welche Erkenntnisse bis zum Abend gewonnen werden können.

Dies deckt sich zum großen Teil auch mit den Erfahrungen, die ich bis Dato machen konnte. Schade finde ich es, dass der Performance-Vergleich z.B. nicht auf die einzelnen Bindings der WCF eingeht – aber der Artikel will ja primär die neue Technologie mit der alten vergleichen. Ich für meinen Teil durfte feststellen, dass für HTTP das BasicHttpBinding das schnellste ist. Wen wundert’s, es ist auch das einfachste.