Flominator's Kruschtelecke

Nach der Session Clean Code Developer und einem weiteren leckeren Mittagessen, folgte die letzte Session, die ich noch besuchen konnte: Christian Binder informierte darin über Neuheiten zur kommenden Version der Entwicklungsumgebung aus dem Hause Microsoft. Da wir im Unternehmen "nur" Visual Studio und kein Team System einsetzen, war es für mich stellenweise ein wenig schwer, den Ausführungen zu folgen. Hier sind die Punkte, die ich (zumindest ansatzweise) verstanden habe und die mir notierenswert erschienen:

• UI-Automation-Testing (Coded UI-Test/ Test Edition)
  • Elemente aus UI greifen und automatisieren
  • unterstützt werden sollen Win32, WinForms, WPF und Document Object Model von Internet Explorer und Firefox
  • später auch Silverlight (Community Technology Preview nach RTM von VSTS 2010)
  • nutzt Accessabillty-Frameworks wie UIA von Anwendungen zur Barrierefreiheit (Screen Reader etc.)
  • Controls von Drittanbietern müssen gewisse Schnittstellen implementieren, damit auch sie erfasst werden
• Tools für manuelles Testen
  • Anlegen eines Work-Items "Testcase", das an Requirement/UserStory hängt
  • spezielle UI für Tester, die keine Entwickler sind (Manual Test Runner/Test Edition oder Test Essentials)
  • Tester klickt durch und nimmt dies ggf. per Rekorder auf
  • Screenshots und Videoaufzeichnung des manuellen Tests möglich
  • Bugs können direkt aus dem Manual Test Runner erzeugt werden
  • Integration mit Team Test Lab
  • Umwandlung in einen kodierten Test (C#) möglich
• Team Test Lab
  • Environment (derzeit als Hyper-V evtl. später auch als virtuelle Maschine per vmWare-Schnittstelle) aus Buildprozess heraus erzeugen und Build nach dort deployen
  • Verbindung mit Requirements
  • kann in Verbindung mit dem Manual Test Runner verwendet werden, um Tests gegen diese Test Environments auszuführen
  • Screenshot bei Verletzung eines Requirements
  • ggf. Erzeugung eines neuen Bugs mit der virtuellen Umgebung im Anhang (sehr schnelle Reproduktion möglich)
• Test Impact Collector
  • feststellen, welche Tests überhaupt von einer Änderung betroffen sind und durchlaufen werden sollten
  • Unit-Tests und manuelle Tests
• Oberfläche der neuen IDE ist komplett in WPF geschrieben
  • bei Microsoft intern von über 3000 Anwenden genutzt
• durch Extensibility API stark auf Erweiterbarkeit ausgelegt
• UML/DSL-Designer in Architect Edition (Arc Edition)
  • Kommunikationslinien zwischen den einzelnen Architekturschichten können mit Code verglichen werden -> unzulässige Kommunikationen im Code finden (oder auch zwischen Namespaces)
  • keine veralteten Architektur-Flipcharts mehr
  • erlaubt Reverse Engineering: Methodenaufrufe -> Sequenzdiagramm
  • Analyse von Codeabhängigkeiten
• Profiler (Developer Edition)
  • besonders hilfreich bei Threading-Problemen
  • während der Entwicklung von Windows 7 genutzt, um Performace-Probleme zu lösen
  • Hotpath zeigt an, wo meiste Rechenzeit liegen gelassen wird
  • Testcase-Profiler kann Auswirkungen von Änderungen auf die Rechenzeit zeigen
• komfortableres Reporting, daher können Entscheider sich zukünftig selbst ihre Zahlen ziehen und entlasten damit die Entwickler
• langsame Anwendungen können bald nicht mehr durch neue Rechner beschleunigt werden, wenn sie Single-Threaded arbeiten und nur wenige der Multiprozessoren dadurch belastet sind
• Verfolgen von Veränderungen in (Changesets) in Branches

Fazit: Es scheint ein sehr umfangreiches Entwicklungssystem zu werden, das den Entwickler und alle restlichen Beteiligten eines Softwareprojektes in großem Maße unterstützen wird. Da solche Qualität ihren Preis hat, bleibt jedoch fraglich, welche Unternehmen sich das leisten können, leisten wollen und leisten werden ...

Update: Dank geht an Christian Binder für das Feedback. Bitte schaut euch seine kurzen Videos zur Beta 1 an.

Die vorletzte Session auf dem Open Space, die ich nach Testen/Getting Things Done besucht habe, drehte sich um das Programm Clean Code Developer von Ralf Westphal und Stefan Lieser. Letzterer war höchstpersönlich anwesend, um uns in die Geschichte und die Details von CCD einzuweisen:

• guter Entwickler erzeugt Qualität -> hält seine Werte ein
• Analogie dazu: (Guter) Arzt wäscht sich vor Operation die Hände und lässt sich das nie nie nie ausreden
• Werte für Codequalität
  • Korrektheit (funktional, optisch, leistungsfähig, ..)
  • Evolvierbarkeit (Einbau desselben Features kostet zu jedem Zeitpunkt gleich viel)
  • Produktionseffizienz
  • Reflexion
• Ergebnis: 40 Bausteine zum Erreichen von mehr Codequalität
• Aufteilung in fünf Grade
• zur Festigung wird jeder Grad mindestens 21 Tage gehalten
• am Ende wird wieder von vorn begonnen, da man immer noch besser werden kann
• Dokumentation des aktuellen Grades über ein Armband
• Armband bringt Leute ins Gespräch und hilft, die Idee zu verbreiten
• nicht alle Entwickler interessieren sich für sauberen Code
• häufig ist keine Zeit zur Einarbeitung vorhanden.
• Ist das Erlernen neuer Fertigkeiten zu Erhaltung der Arbeitskraft in der täglichen Arbeitszeit erhalten oder muss man dafür in der Freizeit investieren? Es hängt vom Lohn ab
• These: es dauert nicht länger, Clean Code zu schreiben, als Crappy Code (zumindest langfristig gesehen)
• Python und Ruby on Rails liefern bereits beim Anlegen eines neuen Projektes ein Verzeichnis für Unit-Tests, warum nicht auch Visual Studio?
• Grenze zwischen PHP (unsauberes Skripting, bä bä bä) und Java (ganz toll objektorientiert mit Unit-Tests und so) ist deutlich. Bei C# sind die ganzen VB-Pfuscher durch .NET auch im Boot.
• Microsoft vermarktet häufig nur Tools, die dem Benutzer mit viel Klickibunti das Leben erleichtern. Codequalität scheint ein wenig vernachlässigt zu werden.

Fazit: Bei uns im Büro erfuhr ich bereits Ende letzten Jahres von dieser Initiative. Ich hatte sie mir auch bereits auf "vielleicht/irgendwann" notiert, aber bisher noch keinen konkreten Einstiegspunkt für mich gefunden. Nun scheint es mir, dass man auch ohne den Kauf des Buches aktiv loslegen kann. Vermutlich werde ich daher in den nächsten Wochen die Seite zum roten Grad in Angriff nehmen ...

Testing
Die erste Session am Sonntag hatte mit "Testen" ein etwas zu umfangreiches Themengebiet. Daher ging die Diskussion nicht ganz in die Richtung, die ich mir gewünscht hätte. Trotzdem gab es ein paar erwähnenswerte Infos:

• UI-Tests lohnen sich vermutlich nur für Standardarbeitsschritte, sonst zu hohes Preis-Leistungs-Verhältnis
• Webtests sind meist trivial und finden keine richtigen Fehler
• Visual Studio (in welcher Edition?) erlaubt Klickreihenfolge im Browser abzuspielen und als Lasttest mehrfach auszuführen
• Lasttests bei ERP-Systemen heißt, einmal die Weihnachtszeit nachzuspielen
• Tester stumpfen bei häufiger Wiederholung ab und sehen Fehler nicht mehr => Vorteil von UI-Tests
• bestes Preis-Leistungsverhältnis haben Unit-Tests für Rechenfunktionen

Getting Things Done
Nachdem mich das klingelnde Handy aus dem Raum geholt hatte, entdeckte ich eine kleine, aber eine Diskussionssrunde zum Thema Getting Things Done. Obwohl es nicht direkt um das Buch ging, gab es auch dort ein paar Anregungen:

• alle Mails nach dem Urlaub löschen -> wer etwas will, der kommt schon wieder
• (wirklich) dringende Sachen sollten per Telefon geschehen, dort ist auch Rausreißen aus der aktuellen Tätigkeit legitim
• Was ist schon wirklich dringend?
• Abteilungsleiter veröffentlicht seinen Wochenplan, damit seine Untergebenen sehen, was er die Woche über tut
• Corporate-Mikroblogging wie Yammer kann ebenfalls dabei helfen, zu sehen, was die Leute um einen herum so tun

Nachdem zu Inversion of Control und Dependency Injection auf dem Open Space in Ulm keine Fragen mehr kamen, handelten wir spontan noch zwei andere Themen ab:

Mocking

• "normale" Frameworks wie z.B. Rhino Mocks nutzen Proxy-Mechanismusmit Vererbung
• Problem: statische Klassen sind nicht mockbar
• Typemock erlaubt Nutzung der Profiler-API; dadurch auch Mocking statischer Objekt möglich (Date.Now trotzdem nicht)
• Frameworks mit Automock-Funktionalität ermöglichen es, dynamisch zu mocken, was gerade benötigt wird
• RhinoMocks nutze früher Record-Replay-Modus, heutiges Prinzip ist Arrange-Act-Assert
• siehe auch: Einfacheres Mocken von Eigenschaften eines Objektes

Interfaces

• Interfaces verhindern, dass man "virtual" vergisst
• abstrakte Basisklassen können bereits Funktionalitäten implementieren
• Methoden abstrakter Basisklassen können ggf. überschrieben werden, MÜSSEN sie aber nicht
• Interfaces erfordern bei Erweiterung neue Methoden in allen von ihnen abgeleiteten Klassen
• Methoden von Interfaces müssen nicht implementiert werden, wenn die Basisklassen sie bereits implementieren
• Kommentare zu Methoden des Interfaces sollten per Konvetion dort im Interface geschrieben werden, nicht in der Implementierung
• alternativ können mit ghostdoc Kommentare von beerbten Objekten kopiert werden

Fazit
Mein Highlight der zweiten Hälfte der Session waren das Beispiel für das neue Arrange-Act-Assert-Schema bei RhinoMocks sowie der Verweis auf ghostdoc. Dieses Tool kann ich nur wärmstens empfehlen, um automatische Dokumentationskommentare zu generieren. Meist sind sie relativ treffend, falls nicht, sind sie dann zumindest lustig.

Nach dem "Kampf" von Castle Monorail vs. Microsoft MVC geht es heute um Inversion of Control bzw. Dependency Injection. Hier also meine Notizen zu diesem spannenden und häufig unterschätzten Thema:

• Klasse bezieht von ihr genutzte Klassen "von außen"
• Nutzung von Interfaces statt konkreter Implementierung
• Zuweisung des konkreten Objektes "von außen" - manuell oder per IoC-Container
• Konfigurationsstrategien für den Container
  • via XML - aufwändig, bäääh!
  • Objekte einzeln und "von Hand" hinein packen
  • relevante Objekte per Reflection aufsammeln (+ Sonderfälle explizit zuweisen)
    • StructureMap (gut strukturiert)
    • WindsorCastle (wenn man schon Monorail oder ActiveRecord nutzt)
    • Unity
    • Ninject
    • Spring
    • "von Hand" per Attribut
• Constructor injection: wenn keine Default-Implementierungen vorhanden sind
• Setter injection: praktisch, da nur bei Bedarf Default-Implementierungen überschrieben werden
• Performance: Zeitverlust durch IoC im Vergleich zu new ist verschwindend gering im Vergleich zur Lebenszeit des Objektes
• IoC hilft, Singletons zu erzeugen (die im Vergleich zum "normalen" Pattern sogar überschrieben werden können)
• Idealfall: alles wird injiziert
  • Attribute sind nicht injizierbar - Ausweg bietet CommonServiceLocator
• Container lässt sich beim Testen auch ausmocken

Nach den gestrigen Scrum-Notizen hier gleich der Mitschrieb zur nächsten Session vom Ulmer Open Space. Leider gab es in der Session keinen wirklichen Vergleich zwischen den beiden MVC-Frameworks, da niemand der Anwesenden gleichzeitig beide so richtig gut kannte. Trotzdem empfand ich einige Fakten aus der Session als relativ interessant:

• Ziel muss immer sein, die Logik in den Views minimieren
• MS MVC ermöglicht Austausch von Controllern und View-Engines
• weitere Viewengines sind z.B.: NHaml (.NET-Port der bekannten Rails-Engine) und Sparkview
• Webforms sind ebenfalls als Viewengine nutzbar (aber ohne Lifecycle)
• Lock-In-Effekt ist größte Gefahr bei Wahl der Viewengine
• gute Viewengines erlauben Nutzung typisierter Models
• NVelocity-Views zeigen $Variable, wenn selbige nicht gefüllt ist
  • Quelltext nach $ durchsuchen zur automatisierten Fehlersuche
• ASP-View von Monorail kann IntelliSense, MS MVC auch
• Microsoft MVW beherrst ASP Dynamic Data, mit dem man schnell CRUD-Formulare erzeugen kann
• Deployment von MS MVC in bin oder GAC möglich
• Server startet in bestimmten Fällen neu (u.a. bei Änderung zu vieler Dateien)
• Dateiendung muss an ASP.NET übergeben bzw. dafür registriert werden
• Seiten ohne Endung: Bilder und Javascripte explizit per StaticFileHandler bearbeiten, um die Performance zu verbessern.
• Microsofts Lösung kann mit MvcContrib sinnvoll erweitert werden
• Beispiel zum MVC-Framework von Microsoft, das Albert dann ausführlich in einer separaten Session vorstellte.

Fazit: Es gibt keine technischen Gründe, sich für oder gegen Castle Monorail zu entscheiden. Langfristig ist aber (leider?) davon auszugehen, dass es mehr Tools, Support und Community-Angebote für das Microsoft Framework geben wird.

Nachdem Thomas Bandt ja schon erklärt hat, was beim .NET Open Space Süd 2009 so passiert ist, kann ich mich hier ja glücklicherweise auf das Posten meiner Notizen beschränken.

Die erste Session drehte sich um das Thema Scrum:

Einführung

• keine Aussage, wie entwickelt wird - das Team soll dies selbst regeln
• Vorgesetzter kann als Scrummaster problematisch sein, da er "über" den Teammitgliedern steht
• Aufgaben (geforderte Features) für nächsten Sprint werden in Punkten abgeschätzt - NICHT IN STUNDEN
• Länge eines Sprints: 2-4 Wochen, im Web-Bereich häufig nur eine Woche
• keine Belohnungen/Sanktionen, da sonst die Qualität leidet
• Regel: keine neue Karte nehmen, wenn man noch alte hat

Daily Scrum

• Diskussionen abblocken und nach dem Meeting klären
• prägnant erreichte Ziele von heute und geplante Ziele für nächsten Tag nennen, nicht erzählen, was denn so alles über den Tag passiert ist
• Scrummaster muss Probleme heraushören (auch nicht explizit genannte)

Nutzen

• sichtbaren Ergebnis für den Kunden nach jedem Sprint
• starke Kommunikation im Team
• Commitment auf die Aufgabe
• Product owner ist Teil des Teams
  • hat mehr Verantwortung
  • muss während des Sprints zur Verfügung stehen
  • muss klare Vorgaben geben
• mehr Struktur, klare Vorgaben

Gefahren

• Scrum allein enthält keine langfristige Planungskomponente
• evtl. mangelnde Effizienz über Projektlaufzeit
• keine Sicht auf großes übergeordnetes Ziel
• Erfolg steht und fällt mit der Qualität des Backlogs
• keine Basis für Angebotserstellung
  • Lösungsansatz: Spezifikation im ersten Sprint erstellen

Sonstige Themen in der Session

• Release spring: Phase kurz vor einem Release, in der nur noch kosmetische Änderungen durchgeführt werden und parallel relativ zuverlässig getestet werden kann
• Sprint-Burn-Down-Charts zeigen an, wie gut man in der Zeit liegt:

• "Kartenstatus"-Diagramm dient dem gleichen Zweck, spart aber die Malarbeit, durch Zuordnung der Karten zu einem Status:

Fazit
Schöner Rundumschlag zum Thema mit einer guten Mischung aus Theorie und Erfahrungen. Highlight war für mich der Input von Thomas Schissler, der das Konzept seines Unternehmens vorstellte: Dort werden am Anfang zwischen 30 und 60% der Projektlaufzeit für die Erstellung der Oberfläche genutzt. Erst wenn Kunde mit Oberfläche einverstanden ist, wird implementiert. Dies erscheint mir ein sehr sinnvoller Ansatz!

In einer späteren Session erfuhr ich dann auch, was passiert, wenn Scrum falsch eingesetzt wird. In diesem Fall muss SCRUM einfach rückwärts gelesen werden

Nächstes Wochenende geht es (vermutlich) endlich zum FuCamp. Da wird es höchste Zeit, endlich das Kapitel BarCamp Stuttgart abzuschließen und zwar mit diesem Beitrag über die Session von Dennis Kallerhoff.

Dennis vertrat die These, dass die Bedeutung der Email aufgrund neuer Kommunikationsformen (Twitter, Social Networks, etc.) sinken wird. Damit schloss sich die Session nahtlos an jene von Kai Nehm in Offenburg an, ohne diese groß zu wiederholen.

Da er bereits kurz zuvor über das Thema gebloggt hatte, brauche ich auf die Beispiele zu erfolgreich twitternden Unternehmen nicht weiter einzugehen und kann mich einem Detail widmen:

Yammer
Dennis erwähnte beiläufig den Dienst Yammer. Dort kann man ein twitterartiges Netzwerk fürs Unternehmen gründen. Die Zuordnung von Mitgliedern geschieht über die E-Mail-Domain des Unternehmens. Seit einigen Wochen evaluieren wir im Büro nun Yammer. Neben den üblichen Twitter-Features gefällt mir die Möglichkeit, Dateien an die Tweets ääh Yams anzuhängen. Mit Twitterfox existiert auch ein Firefox-Addon zum Dienst, damit man die Seite nicht immer offen haben muss. Zur Krönung lassen sich, nach Verbindung der beiden Accounts, Twitter-Nachrichten über das Hashtag #yam zu Yammer transferieren.

Lustig war mich, dass ich die Notizen zur Session und damit die zu Yammer bis vor ein paar Tagen nicht mehr angesehen hatte. In der Zwischenzeit hatte ich via Synaxon zum zweiten Mal von Yammer erfahren. Gut zu wissen, dass einen die wirklich wichtigen Infos meist mehrfach erreichen

Schon wieder ist eine Woche vergangen und es folgt der nächste Beitrag zum BarCamp Stuttgart. Diesmal berichte ich über Yodas Session Entschleunigung. Die Session war eine Diskussionsrunde, daher gibt es auch keine Präsentation, auf die ich verlinkten könnte. Daher gebe ich hier kurz die Kernaussagen einiger Beiträge als Denkanstoß wieder:

• Grundanliegen der Session: Wege finden, um Tempo aus dem Alltag zu nehmen, um Lebensqualität zu erhöhen
• „Gut Ding will Weile haben“ => Zusammenhang zwischen Zeit und Qualität
• Web-2.0-Zeug hat oft Eigendynamik und frisst jede Menge Zeit: immer online sein, auf keinen Fall etwas verpassen wollen, was im Netzwerk passiert
• Vertiefen ist mehr, als sich durch Wikipedia und Google herausfinden lässt. Man muss dazu Leute anhören und Bücher lesen
• Langsamkeit = Lebensqualität, da Grundlage, sich etwas genauer anschauen zu können
• Buchtipp: Rasender Stillstand
• Entparallelisieren von Tätigkeiten; sich auf eine Sache konzentrieren
• Ist Leistung = Beschleunigung?
• Leistung muss man sehen können?
• Bei welchen Leuten sieht man, dass sie viel leisten? Bei denen, die gestresst und hektisch sind. Leisten sie wirklich viel oder sehen sie nur so aus?
• Problem wurde verstärkt, seit Leistung nicht mehr messbar ist. Woran erkennt man die Leistung, die hinter einer Grafik steckt? An der Anzahl der Pixel?
• Lösungsansatz eines Teilnehmers: Die 4-Stunden-Woche
• selbe Ecke: Beauftragung von Dienstleistern, die einem Arbeit abnehmen: https://getfriday.com/
• anderer Ansatz: Aufgabe erledigt sich oft, wenn man sie einfach liegen lässt — Aufgaben, die aussehen wie ein Schinken: gut abgehangen und daher besser genießbar

Fazit
Für mich war es eine sehr interessante Session, die einige Denkanstöße hervorbrachte. Besonders Leute wie ich, die sich mit Produktivitätsmethoden wie Getting Things Done etc. auseinandersetzen, sollten ab und zu mal das Tempo herausnehmen und nicht nach dem nächsten Produktivitätskick suchen. Wir haben nun einmal nur dieses eine Leben und sollten uns sehr genau überlegen, was wir damit anfangen. Es kann und darf nicht nur aus Arbeit bestehen.

Auf der anderen Seite erklärte mir ein Bekannter, mit dem ich neulich darüber diskutierte, dass er froh sei, ein Workholic zu sein. Wenn sich diese Work auf „Arbeit für einen selbst“ beschränkt und man dadurch mehr Dinge in seinem Leben schafft, als andere, könne er gut damit leben.

Vermutlich ist es wie bei allem: Man darf nicht einfach nur schwarz und weiß sehen, sondern muss auf ein ausgewogenes Gleichgewicht achten.

PS
Gerne hätte ich auf die Literaturliste verlinkt, die Yoda ein paar Tage danach gebloggt hat. Der Link dorthin ist aber leider tot.

Das BarCamp Furtwangen kommt immer näher. Daher wird es für mich wirklich Zeit, zu Potte zu kommen und die letzten Sessions vom BarCamp Stuttgart zu verarbeiten. Klar ist es schon ein paar Tage her, aber dokumentiert hätte ich die Sessions trotzdem gerne.

Die heute vorgestellte Session wurde von Hans Dorsch gehalten und trug den Titel Gute Texte, Schlechte Texte. Eine rein subjektive Betrachtung. Die Präsentation zur Session gibt es bei Slideshare.

Viele der Teilnehmer (auch ich) versprachen sich beim Titel Gute Texte, Schlechte Texte eine Art Anleitung, wie man gute Texte fürs Web schreibt. Die Intention von Hans war aber eine andere: Er wollte uns mit der Session lediglich ein paar Beispiele zeigen, wie gute Texte im Web aussehen können:

Flickr

• persönliche Grußformel in wechselnden Sprachen (ähnlich wie bei der Sendung mit der Maus)
• nicht nüchtern, sondern umgangssprachlich ("unsere funkelnagelneue Homepage")
• aktive Ansprache, eine Aufforderung, was der Besucher tun soll
• keine ausführlichen Erklärungen am Anfang, sondern "Spielen Sie mit den Einstellungen"
• auch FAQs von Flickr lassen gefühlte Freundlichkeit aufkommen
• Fazit: So bekommt die Leute dazu, mitzumachen!

Coolspotters

• Zeigt in einem Satz, um was es geht: "Coolspotters is the Google of people and products..."

MOO

• Slogan "We love to print" findet sich überall wieder.
• Es macht einfach Spaß, dort zu bestellen
• Überall aktive Aufforderungen, was man den als nächstes tun könnte
• deutschsprachiger Warenkorb (nicht selbstverständlich)
• Möglichkeit, der Bestellung einen eigenen Namen zu geben UND die Erklärung, wozu man das brauchen könnte
• Bestellbestätigung auf Seite: "Hurra, deine Bestellung ist eingegangen" und gleich die Warnung, dass man für Karten benutzte Flickr-Bilder nicht löschen soll
• Noch besser ist die Bestätigungsmail, in der erklärt wird, wer bei MOO für was zuständig ist:
• Little MOO verwaltet die Bestellung und Big MOO druckt sie aus. Nur der Kundendienst ist "aus Fleisch und Blut"
• für mich: absolutes Highlight der Session
• mindestens ebenso süß, wie die Einfälle von MOO: das Waschschild bei Puma

Du oder Sie?
Nach diesen Beispielen und einigen weiteren Screenshots (Folien 30-49) ging es zur Frage, ob man den Benutzer dutzen oder sietzen sollte. Auch hier gab es ein paar interessante Fakten zu lernen:

• Dänen dutzen alles und jeden, bis auf die Königin
• Ikea dutzt den Kunden (auch in den Geschäften) - ältere Menschen reagieren meist verwirrt.
• Flickr kann sich nicht so richtig entscheiden und wechselt teilweise auf einer Seite die Anrede
• Omigo redet Verbraucher per Du, Business-Kunden aber per Sie an
• die Kroatin @Rozana erzählte davon, dass sie in ihren ersten Jahren in Deutschland nur "Sie" gelernt hatte. Ihre Freunde, die sie konsequenterweise dann auch mit "Sie" ansprach, dachten immer, sie sei total distanziert und könne sie nicht leiden.
• These: "Du" wird zumindest beim Geldtransfer kritisch (aber, was ist mit dem Barkeeper?)
• @webstyler berichtete, dass "Du" in Kundenbeziehungen eher problematisch ist: Kunde meinte mit "kannst du nicht mal"-Mentalität um kostenpflichtige Dienstleistungen herumzukommen
• Idee zum Abschluss: Entscheidung über Anrede dem Kunden auf der Website überlassen. Damit erkennt er, dass es dem Anbieter wichtig ist.

Fazit
Obwohl die Session in den Augen vieler Teilnehmer total das Thema verfehlt hatte, ergab sich eine höchst spannende Diskussion. Vermutlich wären viele der Teilnehmer gar nicht zur Session gegangen, wenn sie den Titel richtig verstanden hätten, was wiederum die Qualität der Diskussion sehr abträglich gewesen wäre. Von daher war alles gut so, wie es war. Danke an Hans für die interessante Sammlung witziger Texte, für das nachträgliche Hochladen der Folien und für den Tipp mit MOO.