Gestern habe ich über meinen ersten Eindruck von Event-Based Components (EBC) geschrieben. Mein Fazit war sehr positiv – mit dem einzigen Kritikpunkt, dass sich EBCs noch sehr ungewohnt anfühlen und bislang bewährte und etablierte Best Practices fehlen.

Worum geht es bei EBCs überhaupt? Prinzipiell hat Ralf Westphal dies bereits in seinem Blogeintrag EBCs – Der nächste Schritt der Komponentenorientierung? beschrieben. Doch da ich gestern in Reaktion auf meinen Blogeintrag gefragt wurde, ob ich Sinn und Zweck von EBCs noch einmal in meinen Worten erklären könnte, will ich dieser Bitte gerne nachkommen.

Das bisher favorisierte Verfahren zur komponentenorientierten Entwicklung von Software basiert im Wesentlichen auf der strikten Trennung von Implementierung und Kontrakt, so dass Komponenten austauschbar werden – sofern sie den gleichen Kontrakt erfüllen.

Da Komponenten in der Regel nur im Verbund in der Lage sind, eine gestellte Aufgabe zu bewältigen, müssen diese dabei irgendwie miteinander in Kontakt treten. Hierfür enthalten Komponenten Referenzen auf andere Komponenten, von deren Funktionalität sie abhängen. Diese Referenzen verweisen dabei stets nur auf die Kontrakte und nicht auf die konkrete Implementierung.

Um eine Abhängigkeit aufzulösen, muss dann zur Laufzeit entschieden werden, welche konkrete Komponente instanziiert werden soll – wofür üblicherweise die Idee eines Kernels eingesetzt wird, wie beispielsweise in Form eines Dependency Injection-Containers wie LightCore.

So weit, so gut.

Das Problem bei diesem Ansatz zur komponentenorientierten Entwicklung besteht nun darin, dass sich die Reduktion von Komponenten auf ihre Kontrakte zwar positiv auf ihre Austauschbarkeit auswirkt – nicht jedoch auf ihre Unabhängigkeit. Komponenten sind zwar unabhängig von der konkreten Implementierung einer anderen Komponente – aber funktional sind sie dennoch abhängig, nur eben über den Kontrakt.

Dass dies überhaupt ein Problem darstellt, zeigt die Tatsache, dass es nicht möglich ist, eine Komponente nur für sich und isoliert zu testen. In der Regel müssen für andere Komponenten zumindest Stubs, wenn nicht gar Mocks entwickelt und injiziert werden. Das ist aufwändig – zu aufwändig, könnte man mutmaßen.

Denn Komponenten werden häufig mit Lego-Bausteinen verglichen, die man einfach so aufeinander stecken kann – dem Kontrakt sei Dank – doch so wirklich will sich dieses Lego-Gefühl bei der herkömmlichen komponentenorientierten Entwicklung von Software nicht einstellen: Einem roten Lego-Baustein ist es nämlich egal, ob er für sich alleine genutzt wird, oder in Verbund mit einem grünem, einem gelben oder einem blauen.

Ralf nennt diese Eigenschaft topologieunabhängig, weil Lego-Bausteine eben nicht von ihrer Umgebung abhängen. Und genau diese Eigenschaft der Topologieunabhängigkeit trifft auf klassische Komponenten nicht zu: Sie sind abhängig von ihrer Umgebung, allein schon deshalb, weil sie andere Komponenten benötigen, um ihre volle Funktionalität entfalten zu können.

Wendet man sich von Lego-Bausteinen einem anderen Feld, das der IT ein wenig näher steht, zu, kann man problemlos die gravierenden und relevanten Unterschiede zur komponentenorientierten Softwareentwicklung erkennen: Dem Feld von Platinen und Chips.

Ein Chip verkörpert das EVA-Prinzip in Reinkultur: Er erhält Daten per Stromfluss als Eingabe, verarbeitet diese, und gibt Daten per Stromfluss als Ausgabe wieder nach außen. Einem Chip ist es dabei vollkommen gleich, woher die Eingabedaten stammen oder wohin die Ausgabedaten fließen.

Für die Funktionsweise eines Chips sind nun nur zwei Aspekte wichtig:

• Pins: Ein Chip verfügt über Ein- und Ausgabepins, über die er mit anderen Chips verdrahtet werden und mit diesen in Kontakt treten kann. Ob dies geschieht – und wenn ja, in welcher Form – beeinflusst die grundlegende Funktionsweise des Chips jedoch nicht.
• Stromfluss: Den einzigen gemeinsamen Nenner, den zwei Chips aufweisen müssen, damit sie auf funktionsfähige Art miteinander verdrahtet werden können, ist ein gemeinsames Verständnis des Stromflusses. Anders formuliert: Alle an einer Kommunikation beteiligten Chips müssen die gleiche “Sprache” verstehen.

EBCs schließlich sind ein Ansatz, genau dieses Konzept von topologieunabhängigen Komponenten, deren einzige Gemeinsamkeit eine gemeinsame “Sprache” ist, auf Software zu übertragen.

Die Idee dazu ist prinzipiell einfach: Das grundlegende Problem der funktionalen Kopplung von Komponenten basiert auf der Tatsache, dass gegenseitig Methoden aufgerufen werden müssen.

EBCs ziehen aus dieser Tatsache die einzig logische Konsequenz: Wenn diese Art der funktionalen Kopplung vermieden werden soll, dürfen Komponenten keine Methoden anderer Komponenten aufrufen. Statt dessen dürfen sie nur signalisieren, dass sie gerne Daten zur Weiterverarbeitung an andere Komponenten abgeben würden – ob darauf dann eine andere Komponente reagiert oder nicht, betrifft die ursprüngliche Komponente nicht mehr.

In einem Satz zusammengefasst bildet dies den Schlüssel zum Verständnis von EBCs:

Im Gegensatz zu klassischen Komponenten rufen EBCs keine Methoden anderer Komponenten auf, sondern stellen nur den Wunsch nach Weiterverarbeitung ihrer Daten in den Raum.

Damit gewinnt man Topologieunabhängigkeit, denn jede EBC ist von ihrer Umgebung entkoppelt und kann entweder für sich alleine oder transparent im Verbund mit anderen Komponenten genutzt werden. Dass sich die Funktionalität von EBCs damit perfekt per Unittest validieren lässt, liegt auf der Hand. Daher eignen sich EBCs ausgezeichnet auch für die Entwicklung mit 4-Step TDD.

Die einzige verbleibende Frage ist, wie dieses Schema umgesetzt werden kann. Die Antwort ist – nochmals – sehr einfach: Input-Pins entsprechen klassischen Methoden, Output-Pins werden als Events deklariert, woher auch der Name der EBCs rührt.

Passt die Signatur eines solchen Events einer Komponente zur Signatur einer Methode einer anderen Komponente, können beide per Eventbinding von außen miteinander verdrahtet werden – die Komponenten selbst bemerken dies nicht und agieren auch im Verbund ebenso wie sie es isoliert für sich täten.

Dadurch entsteht anders als bei klassischen Komponenten kein Codefluss von direkter Aktion und Reaktion, sondern ein Fluss von Daten: Jeweils eine Komponente verarbeitet Daten und reicht diese danach an eine oder mehrere andere Komponenten weiter.

Auch Rückgabewerte lassen sich auf diese Art realisieren: Statt aus der aufgerufenen Methode einen Rückgabewert zurückzuliefern, wird ein entsprechendes Event ausgelöst – auf das die ursprünglich “aufrufende” Komponente dann entweder reagieren kann oder nicht – je nach Belieben. Der “aufgerufenen” Komponente ist das gleich – sie löst unabhängig von ihrer Umwelt lediglich ihre Events aus.

Dies sind die grundlegenden Ideen von EBCs, im nächsten Blogeintrag wird es dann darum gehen, wie eine konkrete Implementierung einer solchen EBC aussehen und wie diese mit anderen EBCs verdrahtet werden kann.

Vor ungefähr fünf Monaten hat Ralf Westphal in seinem Blog die Frage aufgeworfen, ob nachrichtenorientierte Komponenten den nächsten Schritt der Komponentenorientierung darstellen.

Als entsprechendes Architekturmodell hat die sogenannten Event-Based Components (EBC) vorgestellt: Ein einfaches Komponentenmodell mit einigen kompakten Regeln, dessen wesentliches Merkmal des Einsatz von Events als Kommunikationsmedium an Stelle klassischer Methodenaufrufe ist.

Im Prinzip ähnelt das Konzept der EBCs dem von Chips und Platinen: Ähnlich wie diese können auch EBCs zusammengesteckt werden und größere Komponenten bilden. Der Vorteil des Ganzen liegt in einer ausgesprochen geringen Kopplung – effektiv sind die einzelnen EBCs nicht mehr voneinander, sondern nur noch von gemeinsamen Typen abhängig.

Die funktionale Abhängigkeit ist aufgelöst. Die Vorteile liegen auf der Hand: EBCs sind einfacher zu instanziieren, einfach zu komponieren, einfacher zu isolieren und daher auch einfacher zu testen.

So weit, so gut. Die Frage ist, inwieweit dieses theoretisch interessante Konzept in der Praxis funktioniert.

In den vergangenen Tagen hatte ich die Gelegenheit, einen EBC-basierten Prototypen einer bestehenden Anwendung zu erstellen: Die zu erzielende Funktionalität war also vorgegeben, die einzige Aufgabe war also tatsächlich, das Konzept der EBCs in die Praxis umzusetzen.

Inzwischen ist dieser Prototyp so weit gediehen, dass er die ersten funktionalen Anforderungen der ursprünglichen Anwendung erfüllt. Zeit, im Rahmen einer kleinen Retrospektive zurückzublicken und ein erstes Fazit zu ziehen. Die aus meiner Sicht zwei wesentlichsten Aspekte sind:

• EBCs sind effizient: EBCs ersparen einem die Mühe, eine aufwändige Architektur zu entwickeln – sie implizieren eine kompakte Form. Diese kann in technischer Hinsicht auch leicht umgesetzt werden – auch oder erst recht mit TDD. Die geringe Kopplung wirkt sich hierfür enorm positiv aus. Die Erweiterbarkeit des gesamten Systems ist beeindruckend, und auch die Wart- und Evolvierbarkeit des Codes können sich sehen lassen. Noch mehr als von TDD alleine wird man durch den Einsatz von EBCs mit TDD gezwungen, sich zuvor fundierte Gedanken über das Design der Komponenten zu machen.
• EBCs sind ungewohnt: Der größte Makel von EBCs ist – für mich persönlich – derzeit ihre Andersartigkeit. Sie fühlen sich schlicht und ergreifend ungewohnt an, denn die Kommunikation zwischen den Komponenten folgt nicht mehr dem klassischen und zur Genüge gewohnten Aktion-Reaktion-Schema. Statt dessen modellieren EBCs einen Fluss von Daten durch die Anwendung. Die größte Herausforderung in den vergangenen Tagen war, gedanklich immer wieder zu diesem Fluss-basierten Modell zurückzukehren und sich zu überlegen, wie Funktionalität als Fluss implementiert werden kann.

Natürlich ist der zweite Punkt reine Gewohnheits- und Übungssache. Je öfter man EBCs modelliert, desto leichter gelingt dies. Der Einstieg in EBCs ähnelt daher dem Einstieg in TDD in gewissem Sinne – es ist gar nicht so sehr das rein technische Vorgehen, das kann kompakt und übersichtlich veranschaulicht werden, sondern es sind das fehlende Gefühl für EBCs und die fehlenden Best Practices.

Während das Gefühl nur jeder für sich entwickeln kann, indem er sich mit EBCs beschäftigt und die Arbeit mit ihnen ausprobiert, können Best Practices vermittelt werden – falls diese bereits bekannt sind. Hierzu ist es notwendig, einen Konsens oder zumindest verschiedene, fundierte und argumentativ belegte Meinungen zu finden.

Ralf hat zu EBCs seine Sicht der Dinge – ich habe meine. Aus diesem Grund werde ich in den kommenden Tagen viel über meine Erfahrungen und Erkenntnisse bezüglich EBCs schreiben.

Wenn ich eine andere Meinung vertrete oder EBCs anders nutze als Ralf, werde ich dies begründen – nicht, um Ralfs Position zu schwächen, sondern schlichtweg, um einen zweiten Standpunkt darzulegen.

Vielleicht ergeben sich in der Synergie aus Ralfs Sichtweise, meiner Sichtweise und der Sichtweise von allen anderen Verwendern von EBCs ja Best Practices, die es wert sind, weitergetragen zu werden.

EBCs an sich sind dies allemal wert – sie sind ein großartiges Konzept, das mir sehr gut gefällt. Der langfristige Nutzen wird sich noch beweisen müssen, aber so weit ich EBCs bislang beurteilen kann, sind sie definitiv ein wichtiger Schritt in die richtige Richtung für die moderne Softwareentwicklung.

Am 1. Januar 2010 hat Peter Bucher einen eigenentwickelten Dependency Injection-Container namens LightCore vorgestellt. Heute Nacht, nahezu acht Monate später, ist die neue Version 1.4 erschienen, zudem wurde die Webseite grundlegend überarbeitet, ist nun über die eigene Domain www.lightcore.ch erreichbar und wartet unter anderem mit einem neuen Design auf.

Was ist neu in LightCore 1.4?

Bemerkenswertestes Feature ist nach wie vor die hohe Ausführungsgeschwindigkeit, die andere Dependency Injection-Containern im Vergleich weit hinter sich lässt. Abgesehen von klassischer Objekterzeugung per new-Schlüsselwort ist mir kein schnellerer Weg bekannt, Objekte zu instanziieren.

Doch abgesehen davon gibt es auch noch einige echte Neuerungen, die es durchaus wert sind, einzeln genannt zu werden:

• Unterstützte Plattformen: LightCore 1.4 steht nunmehr für .NET 4.0, .NET 3.5, Silverlight 3 und das .NET Compact Framework 3.5 zur Verfügung.
• Collections: LightCore 1.4 ist nun in der Lage, mit Collections umzugehen. Das bedeutet: Werden beispielsweise mehrere Implementierungen von IFoo registriert, wird ein Parameter vom Typ IEnumerable<IFoo> automatisch erwartungsgemäß aufgelöst.
• Dynamische Argumente: Erwartet eine Komponente die Übergabe von Parametern, so stand bislang nur die statische Angabe dieser Parameter während der Registrierung zur Verfügung. LightCore 1.4 ermöglicht nun auch den Einsatz von dynamischen Argumenten, das heißt, von Argumenten, die erst zur Laufzeit übergeben werden.
• Verzögerte Instanziierung: Zumindest in der für .NET 4.0 kompilierten Version bietet LightCore 1.4 Unterstützung für den in .NET 4.0 eingeführten Lazy<T>-Typ, mit dessen Hilfe die verzögerte Instanziierung von großen Objekten – quasi on Demand – möglich wird.
• Property Injection: Zwar ist Property Injection auch in LightCore 1.4 nach wie vor nur optional verfügbar – sie ist dafür aber um einiges schneller geworden. Wer also auf Property Injection nicht verzichten kann, erhält zumindest eine deutlich beschleunigte Ausführung.
• Lizenz: Endlich ist auch die Frage geklärt, unter welcher Lizenz LightCore verfügbar ist. Prinzipiell gilt: Im Binärformat darf LightCore in Projekten jeglicher Art genutzt werden, als Quellcode steht LightCore unter der Ms-RSL für Referenzzwecke zur Verfügung. Änderungen wie auch abgeleitete Werke sind nicht gestattet.

Darüber hinaus enthält LightCore 1.4 noch zahlreiche weitere kleine Neuerungen – wie beispielsweise eine vollständige Abdeckung durch Unittests, im Vergleich zu Version 1.0 deutlich aufgeräumteren und besser refaktorisierten Quellcode und eine bessere Fehlerbehandlung.

Erwähnenswert ist allerdings auch noch ein Breaking Change im Vergleich zu Version 1.0: Benannte Registrierungen sind entfallen. Damit war es möglich, auf eine einzige Schnittstelle verschiedene Implementierungen zu registrieren, die nur durch ein händisch vergebenes Tag unterschieden werden konnten. Zur Ausführungszeit konnte dann mittels dieses Tags angegeben werden, welche konkrete Implementierung instanziiert werden soll.

Die Begründung, warum dieses Feature in LightCore 1.4 entfallen ist, findet sich in meinem Blogeintrag Welche Bedeutung wohnt einer Schnittstelle inne?. Für mich persönlich stellt dieser Breaking Change einen Schritt in die richtige Richtung dar, weshalb ich mit damit gut leben kann.

Insgesamt kann ich mein Fazit für Version 1.0 damit auch für Version 1.4 weiter verwenden:

Alles in allem ist LightCore also eine kompakte, performante, flexible und ausgereifte Komponente, die für meine Projekte zukünftig die Antwort auf die Frage nach einem geeigneten Microkernel darstellt.

Auch weiterhin bleibt LightCore für mich also der Dependency Injection-Container meiner Wahl.

Am 8. Juli 2010 fand in der Universität Augsburg der erste Agile Day statt, zu dem ich als Referent eingeladen war.

Nach einer allgemeinen Einführung wurde zunächst Scrum vorgestellt, wobei der Praxis ein sehr großer Stellenwert eingeräumt wurde: Die ungefähr 20 Teilnehmer erhielten auf diese Art die Gelegenheit, diverse Schritte selbst durchzuführen.

Mir persönlich fällt bei Scrum immer wieder auf, dass die Schere zwischen Theorie und Praxis extrem auseinanderklafft: Einerseits hat man Scrum durchaus in fünf Minuten auf einer Serviette erklärt. Andererseits stößt man während der praktischen Umsetzung auf dermaßen viele Probleme, dass man gut beraten ist, jemanden mit Scrum-Erfahrung in verfügbarer Nähe zu haben.

Im Anschluss an diese sehr dynamische und interaktive – und auch sehr gut gemachte – Einführung in Scrum habe ich in meiner Session einen kurzen Überblick zu Unittests im Allgemeinen und Test-Driven Development (TDD) im Speziellen gegeben.

Auch ich habe neben der Theorie großen Wert auf die Praxis gelegt, weshalb ich den Teilnehmern in einer Art Dojo die Aufgabe gestellt habe, die Kata FizzBuzz zu lösen – auch wenn wir dies in der gegebenen Zeit nicht geschafft haben, war der Lerneffekt im Hinblick auf TDD meines Erachtens sehr groß.

Zum Abschluss des Agile Days wurde eine sogenannte Extreme Hour angeboten, in der eine vorgegebene Aufgabe mit den Praktiken von Extreme Programming (XP) erledigt werden sollte – inklusive kurzer Iterationen und ähnlichem.

Durch das große Interesse, die vielen Fragen und die ungewöhnlich hohe Bereitschaft der Teilnehmer, aktiv mitzumachen, war nicht nur die Extreme Hour, sondern auch der gesamte Agile Day ein großer Erfolg, der – nicht nur mir – sehr viel Spaß gemacht hat.

Der nächste Agile Day wird am 29. Oktober 2010 stattfinden.

Scrum als agile Methode verlangt ein dediziertes Dokument, in dem definiert wird, wann Code als “fertig” anzusehen ist. Dieses Dokument wird als Definition of Done bezeichnet und dient allen Beteiligten als gemeinsame Basis zur Abnahme von Code.

Mir gefällt diese Idee.

Allerdings fordert Scrum nur, dass es ein solches Dokument geben muss – es wird jedoch keinerlei Aussage dazu getroffen, wie eine entsprechende Definition aussehen könnte.

Hieran zeigt sich wieder das typische Problem von Scrum: Es bietet nur einen Rahmen, aber keinen Inhalt. Das macht Scrum sehr portabel und vielfältig einsetzbar, das macht Scrum aber auch sehr unspezifisch.

Aus diesem Grund habe ich mir Gedanken gemacht, welche Eigenschaften Code für mich aufweisen muss, um als “fertig” gelten zu können. Entstanden ist meine ganz persönliche Definition of Done.

Code is considered to be “done”, when:

1. It does satisfy all its functional and non-functional requirements.
2. It does not contain any known errors.
3. It has been commented and documented.

4. It has been either pair-programmed or reviewed.
5. It has been developed test-driven using 4-Step TDD.
6. It does not need to be refactored or rearranged.

7. It has been written according to well-known best practices.
8. It does conform to accepted coding standards.
9. It does pass static code analysis without any errors or warnings.

10. It has been integrated and does not break the integration build.
11. It has been checked in into source control.

Wenn Code all diese Punkte erfüllt, kann man den dazugehörigen Task in meinen Augen guten Gewissens als abgeschlossen betrachten.

Den Teilnehmern des dotnetpro.powerdays C# für Profis wurde im Anschluss an die eigentliche Veranstaltung die Teilnahme an einem .NET Coding Dojo angeboten, das von Ilker Cetinkaya durchgeführt wurde.

Im Rahmen dieses Dojos wurde die Frage diskutiert, wie der übliche TDD-Cycle Red – Green – Refactor auszulegen sei. Stein des Anstoßes war, dass einige Teilnehmer den Schritt Refactor als optional angesehen haben und ihn daher im konkreten Fall außen vor lassen wollten – was bei anderen Teilnehmern wiederum für Unmut sorgte.

Ich selbst habe die Meinung vertreten, dass der Schritt Refactoring keineswegs optional sei, denn stellt man diesen in Frage, öffnet man seinem gänzlichen Ausschluss Tür und Tor – dem verführerischen Weg zur Brownfield-Anwendung wird damit Vortrieb geleistet.

Einige Teilnehmer des Dojos – allen voran Stefan Lieser – haben argumentiert, dass ein Refactoring am Ende des TDD-Cycles keinen Sinn machen würde – sondern dass es vielmehr an den Beginn dieses Zyklusses verschoben werden sollte, schließlich sei Refactoring auf ein Ziel und somit auf einen Plan angewiesen – sonst wisse man nicht, in welche Richtung das Refactoring zu treiben sei.

Stefan hat dies in seinen Blogeinträgen Refaktorisieren im TDD Prozess und TDD 2.0 dargelegt – allerdings bin ich davon nicht überzeugt. Ein Refactoring zu Beginn des TDD-Cycles macht keinen Sinn: Erstens aus dem bereits genannten Grund, der Verschmutzung von Code Vortrieb zu leisten, zweitens weil ich direkt zu Beginn eines Projektes kein Refactoring betreiben kann.

Auch wenn es sich hierbei nur um eine einzige Ausnahme handelt, in der die von ihm vorgeschlagene Regel nicht greift – es ist eine Ausnahme, was ich persönlich nicht schön finde.

Für mein Empfinden gibt es zwei Arten von Refactorings: Einerseits kleine, kosmetische Korrekturen, andererseits grundlegende, Architektur-betreffende Änderungen. Stefan beschreibt diese Aufteilung ebenfalls – zieht für mein Empfinden aber die falschen Schlüsse.

Natürlich ist es – wenn überhaupt möglich – schwierig, grundlegende, Architektur-betreffende Änderungen durchzuführen, wenn man noch nicht weiß, in welche Richtung die Software weiterentwickelt werden soll.

Diese Art von Änderungen ist jedoch gar nicht das, was in der Regel von Refactoring betroffen ist: Ob ich Code in eine private Methode auslagere, um DRY umzusetzen, ist unabhängig von der Architektur. Ebenso, ob ich ein Literal in eine Konstante auslagere oder nicht.

Diese Art von Refactorings macht den bedeutend größeren Anteil aus – es wäre auch tragisch, wenn Entwickler und Architekten nach jedem Test beständig damit beschäftigt wären, die Architektur grundlegend anzupassen.

Es liegt auf der Hand, dass diese Art von kosmetischen Korrekturen direkt nach dem Schritt Green ausgeführt werden sollten – ganz so, wie TDD es in seiner Urform vorschreibt: Red – Green – Refactor.

Die Architektur-bezogenen Änderungen werden in diesem Schema aus drei Schritten also gar nicht berücksichtigt: Die logische Konsequenz daraus ist die Einführung eines vierten Schrittes, der getrennt von Refactor stattfinden kann.

Da dieser vierte Schritt wesentliche Änderungen behandelt, die das architektonische Grundgerüst des Codes betreffen, nenne ich diesen Schritt Rearrange – schließlich werden die einzelnen Komponenten und deren Verdrahtung zueinander in diesem Schritt neu arrangiert und komponiert.

Dieser vierte Schritt ist – naturgegeben – erst dann sinnvoll, wenn bekannt ist, in welche Richtung die Entwicklung laufen soll. Ihn aber direkt in den TDD-Cycle aufzunehmen, halte ich für unglücklich – schließlich wird er nicht nach jedem Durchlauf angewendet. Daher plädiere ich für zwei Zyklen, die einander enthalten:

TDD = Red – Green – Refactor

als klassischer TDD-Cycle für kosmetische Korrekturen und

TDD erweitert = TDD – TDD – … – TDD – Rearrange

als erweiterter TDD-Cycle für architektur-bezogene Anpassungen, Änderungen und Erweiterungen.

Den Schritt Rearrange habe ich bewusst am Ende des erweiterten TDD-Cycles untergebracht, denn vor der ersten Ausführung von TDD ergibt die Durchführung von Rearrange keinen Sinn – und da eine Software nie “fertig” ist und es daher stets einen weiteren TDD-Cycle geben wird, habe ich keinerlei Bedenken, Rearrange an die letzte Position zu schieben.

Der erweiterte TDD-Cycle hat in diesem Sinne nämlich keinen Anfang und kein Ende mehr, sondern stellt eher einen Fluss dar – welche Vorbedingungen für den jeweils nächsten Schritt erfüllt sein müssen, darüber wird keine explizite Aussage gemacht. Implizit jedoch erfordert Rearrange Planung, womit auch Stefans Wunsch nach mehr Planung berücksichtigt wäre.

Angeregt durch den sehr verständlichen und empfehlenswerten Artikel Der Trick mit den Karten von Matthias Lohrer in der dotnetpro 08.2010 habe ich das Buch Kanban and Scrum – Making the Most of Both von Henrik Kniberg und Mattias Skarin bestellt und in den vergangenen Tagen gelesen.

Es vergleicht – wie der Titel bereits andeutet – Kanban und Scrum, wobei die erste Hälfte des Buches den reinen Fakten gewidmet ist, die zweite Hälfte hingegen ein Fallbeispiel nachzeichnet, so dass so wohl Theorie wie auch Praxis entsprechend gewürdigt werden.

Als besonders angenehm habe ich empfunden, dass Kanban and Scrum nur 120 Seiten umfasst, dennoch aber alle relevanten Aspekte anspricht und diese zielgerichtet auf den Punkt bringt.

Da die Auswahl an Literatur zu Kanban im Vergleich zu Extreme Programming (XP) oder Scrum verhältnismäßig gering ist, finde ich es desto erfreulicher, dass ein dermaßen kompaktes, verständliches und kurzum lesenswertes Buch zu Kanban existiert.

Wer sich also für Kanban interessiert und bereits über Erfahrungen mit Scrum verfügt, dem sei das Buch sehr ans Herz gelegt – es lohnt sich.

Ilker Cetinkaya, Berater, Architekt und Entwickler bei Avanade Deutschland GmbH, entwickelt Software mit dem Microsoft .NET Framework seit der Version 1.0. Durch sein langjähriges Wirken bei großen Projekten prägt ihn ein breites und tiefes Know-How, besonders in den Themen Skalierung, Performance und Flexibilität von .NET Anwendungen; sowohl im Web- als auch im Enterprise-Umfeld. Als ausgewiesener Experte für professionelle Software-Entwicklung beschäftigt er sich seit mehreren Jahren intensiv mit den Themen agile Methoden, TDD / BDD, C# 3.0 / 4.0 und Software-Design. Sie erreichen ihn über sein Blog.

Golo Roden: Ilker, wie bist Du zur Softwareentwicklung gekommen? Wie und wann hast Du angefangen?

Ilker Cetinkaya: Ich glaube ich war 9 oder 10 Jahre alt, als ich das erste mal mit Rechnern in Berührung kam. Klassischerweise war es natürlich der C64 mit Datasette. Zunächst habe ich nur gespielt. Auf dem C64 selbst habe ich gerade mal PEEK, POKE und LOAD beherrscht. Ein paar Jahre später ging es dann aber mit dem Amiga 500 richtig zur Sache. Zunächst noch Spielen und Programmieren in frequentivem Wechsel, doch mit der Zeit faszinierte mich das "Anprogrammieren" der Maschine immer mehr.

Anfangs habe ich mich noch sehr auf die "Standards" wie kleine Hilfsprogramme und Verwaltungsanwendungen konzentriert. AmigaBasic war da schon ein probates Mittel. Doch bald trieb es mich in die Spiele- und Grafikprogrammierung. Agnus, Denise, Paula und ich wurden dicke Freunde. Programmiert habe ich damals viel in Blitz, AMOS, C sowie einem C-Derivat namens "Amiga E". Nun, nach vielen und langen Jahren auf der Amiga-Plattform - wir wissen ja, wie die Amiga-Geschichte verlief, oder? - "musste" ich auf die x86er-Plattform und war natürlich zunächst drastisch enttäuscht. Doch bald fand ich dort mit Borland C und Borland Pascal meine "Programmierwelt" wieder, in die ich eintauchen konnte.

Nach vielen weiteren Sprachen und Szenarien kam ich dann Anfang 2001 zu den NGWS und C#. Zunächst natürlich nur aus Interesse und Spielerei, nebenbei machte ich sehr viel in C, PHP, ASP und Visual Basic 6. Erstaunlicherweise ließ aber der Alltagsgebrauch nicht sehr lange auf sich warten, denn ich durfte bei meinem damaligen Arbeitgeber schon 2003 meine ersten Anwendungen in C# entwickeln.

Tja, und heute bin ich immer noch beim .NET Framework und bei C# - und ich bin damit auch recht glücklich.

Golo Roden: Außer mit .NET beschäftigst Du Dich auch intensiv mit agilen Methoden, insbesondere Scrum. Wie kam es dazu?

Ilker Cetinkaya: Ich habe mich für agile Software-Entwicklung um die Jahre 2003 / 2004 angefangen zu interessieren. Lustigerweise aus dem trivial-naiven Grund, dass mich der Name "Extreme Programming" einfach gereizt und neugierig gemacht hat. Damals dachte ich mir: "Yeah, Extreme Programming - klingt krass, muss ich unbedingt mal probieren". Aus diesem "mal probieren" wurde dann aber ganz schnell ein ernsthaftes auseinandersetzen. Ich habe dann Stück für Stück mich intensiv mit XP auseinandergesetzt und es sukzessive - anfangs leider nur in Teilen - umgesetzt.

Durch diese intensive Zeit bis 2007 habe ich vieles über Agilität und Methoden gelernt. 2008 schließlich war es an der Zeit, Scrum näher zu erkunden, weil es mit XP und FDD zur Auswahl stand als Software-Entwicklungs-Methodik in meiner damaligen Firma eingesetzt zu werden. Nun, man hat sich für Scrum entschieden und ich habe mich immer mehr mit dem Thema Scrum beschäftigen dürfen.

Heute kann ich für mich behaupten, zwar einiges schon über Agilität, Scrum, XP und Co. zu wissen. Aber im gleichen Atemzug muss ich auch sagen, dass ich noch einiges darüber lernen will und werde. So beschäftige ich mich zum Beispiel seit über einem Jahr nebenbei mit Lean Management und der Adaption für das Software-Engineering. Gleichzeitig macht es mir auch zunehmend Spaß, immer mehr über TDD, Pair Programming, NLP und Feedback-Loops zu lernen. Die Erkenntnis des Continuous Improvements und des daraus kausal folgenden Lifelong Learnings ist einer der Grundbausteine agiler Handlungsmethodik.

Golo Roden: Welche Rolle spielen agile Methoden Deiner Meinung nach für Anfänger?

Ilker Cetinkaya: Die gleiche Rolle wie auch für Erfahrene oder Experten. Ich bin der festen Überzeugung, das die agile Entwicklungs-Methodik ein wichtiger und großer Schritt hin zu einer neuen Art und Weise der Software-Entwicklung ist. Agile Methoden und Werte sind heutzutage sowohl aus wirtschaftlicher als auch aus professioneller Hinsicht nicht mehr aus dem Tagesgeschäft wegzudenken. Dem Anfänger darf ich den wohlgemeinten Rat geben, sich mit der agilen Software-Entwicklung zügig und intensiv auseinanderzusetzen.

Häufig wird man bei solch einer Aussage mit Antworten wie "Ja, will ich, aber ich weiß nicht wie" oder "Ja, aber bei uns geht das nicht so einfach" oder "Ja, aber wir haben keinen Experten" konfrontiert. Das sind sicherlich Punkte, die für Entwickler Einfluß auf das Lern- und Adaptionsverhalten von Agilität haben. Jedoch sollte man diese Faktoren nicht überbewerten oder unnötigen Respekt vor der Veränderung haben. Agilität ist "salonfähig" geworden. Das bringt zwar auch kritische und ungewünschte Einflüsse mit sich, ist aber im Großen und Ganzen doch positiv.

Denn: Agile Softwareentwicklung ist der Rahmen des modernen, neuen Bilds eines Software-Entwicklers. Das macht es gleichermaßen für den Neueinsteiger sowie auch für den langjährigen "Entwickler-Haudegen" zu einem unübersehbaren - ja ich möchte sogar behaupten zwingenden - Kriterium für den Erfolg als Software-Entwickler. Für den Haudegen, der solche Dinge wie Wasserfall, V-Modell, V-XT oder ähnliches hinter sich gebracht hat, ist es oftmals ein kleines Stück schwerer, sich dem Spirit der Agilität zu nähern.

Golo Roden: Ein wesentliches Merkmal der IT ist, dass man beständig mit neuen Entwicklungen konfrontriert wird, und diesen folgen muss. Woher nimmst Du die Motivation, Dich quasi jeden Tag weiterzubilden und mit Neuem zu beschäftigen?

Ilker Cetinkaya: Es macht mir Spaß! Und das ist kein Witz! Du weißt sicherlich, was ich damit meine, deswegen gehe ich - obwohl es so unglaublich wichtig ist - auch nicht näher darauf ein, sondern möchte auch noch andere Aspekte erwähnen.

Nun, ich denke, dass man in einem Beruf, in dem stetige Neuentwicklung und Neuorientierung "Tagesgeschäft" ist, auch das notwendige emotionale, soziale und intellektuelle Rüstzeug mitbringen sollte.

Emotional, weil Motivation, Spaß, Vertrauen und Neugier oft in kleine und große Emotionen münden und man mit diesen Emotionen auch ein Stückweit umgehen können sollte. Beim Lernen, der Entwicklung und Forschung sind sich Enttäuschung und Euphorie manchmal sehr nah. Hier ist es wichtig, die Emotionen zu verarbeiten und sie "ins richtige Licht" zu rücken. So ist manchmal eine Enttäuschung noch kein Beinbruch, ein Erfolg aber oftmals kein bemerkenswerter Fortschritt.

Sozial, weil Software und Software-Entwicklung längst aus der Nische der Forschung und Technologie herausgetreten sind und sich in unserem Leben verankert haben. Diese Verankerung ist so tief, dass ein Software-Entwickler immer seltener in die Gelegenheit kommen wird, völlig selbstständig und autark ein professionelles Produkt oder eine Dienstleistung ausliefern zu können.

Intellektuell, weil Informationsgesellschaft und Informationsverarbeitung ein herausforderndes Thema sind und bleiben werden. Wir als Gesellschaft sind an einem Punkt, in dem Information ein zentrales Element unseres Lebens einnimmt. Das gilt für uns Geeks und Software-Entwickler umso mehr.

Das hört sich jetzt abgehoben und zum Teil arg philosophisch an. Aber wenn man mal ein paar Minuten darüber in Ruhe nachdenkt, dann fühlt man sich als Software-Entwickler nicht nur in der "Pflicht", neue Dinge zu Lernen, sondern man fühlt sich im "Recht", es zu tun. Und ganz offen: Dafür bin ich dankbar und weiß das auch zu schätzen.

Golo Roden: Wenn sich ein Anfänger heute mit dem Thema Softwareentwicklung befassen will - welche Voraussetzungen sollte er Deiner Meinung nach dafür mitbringen, und was siehst Du als No-Go an?

Ilker Cetinkaya: Ich habe ja gerade schon geschildert, dass man als Software-Entwickler eine Reihe von "Soft-Skills" mitbringen sollte. Vielen Entwicklern, die wie ich schon viele Jahre im Geschäft sind, die selbst schon Plattformen und Technologien "überlebt" haben, wird dieses Thema in letzter Zeit vielleicht etwas zu sehr in den Vordergrund gestellt. Ich jedenfalls höre des öfteren Kommentare wie "Ach, diese Philosophiererei und Esoterik mit Soft-Skills und Agilen Werten ist überbewertet."

Diesen Stimmen kann ich nur entgegnen, dass sie sowohl Recht als auch Unrecht haben. Sie haben Recht, denn ein Software-Entwickler ist kein Philosoph und schon garnicht ein Theoretiker. Es geht um konkrete Technologien und Informationsverarbeitung. Sicheres und hochwertiges Anwenden von Mathematik, Logik und Analytik sind Fähigkeiten, die man als Software-Entwickler zwingend mitbringen sollte. Das gilt für den hardwarenahen NUI-Treiber-Entwickler genauso wie für den CRM-Anwendungs-Entwickler.

Doch sie haben auch Unrecht. Denn ein Software-Entwickler ist mittlerweile kein isoliertes, sein 30qm-Kämmerchen mit Starkstrom versorgendes, sich von Kaffee und Pizza ernährendes, an Platinen und ICs herumlötendes, sich mit exotischen Parkleitsystemen beschäftigendes, alle seine 15 Rechner mit 3D-Landschafts-Rendering auslastendes, am Rande der Gesellschaft sozial abgegrenztes Individuum mehr.

Computer, Hardware, Software, Web, Information - das sind Dinge, mit denen heutzutage nahezu Jeder in Berührung kommt. Diesem Umstand müssen wir auch als Software-Entwickler Rechnung tragen. Das gilt für die Industrialisierung, also die Automatisierung und Globalisierung von Software-Entwicklung, als auch für die Sozialisierung, also die Menschlichkeit und Gemeinsamkeit in der Software-Entwicklung.

Damit sind, denke ich, zwischen den Zeilen auch meine No-Gos für einen Software-Entwickler schon genannt: Eigenbrot-Egozentriker, Un-Logiker, Theorie-Bibel-Prediger, Ellenbogen-Ausfahrer, Kontrollwahn-Ausleber, In-Hierarchien-Strukturierer, Chaos-Leben-Bevorzuger, Oberlehrer-Zeigefinger-Heber, Organisations-Verabscheuer, Gesellschafts-Meider, Möchtegern-Neo-In-Die-Matrix-Hacker, Rosarote-Brille-Aufhaber, Informatik-Rein-Aus-Karrieregründen-Studierer, Algorithmus-Fetischisten oder Kreativ-Kultur-Kult-Hedonisten werden es als Software-Entwickler in Zukunft sehr schwer haben.

Damit könnte ich ein ganzes Buch füllen. Spaß bei Seite, ich hoffe ich konnte klarmachen, dass man meiner Meinung nach heutzutage alleine als Software-Entwickler nicht mehr viel erreichen kann.

Golo Roden: Bei der Vielzahl an Technologien, die es heute gibt: Womit sollte ein Anfänger heutzutage anzufangen?

Ilker Cetinkaya: Schön, dass wir uns von der "Esoterik" wieder zur "Technik" wenden.

Ich finde gerade die Entwicklung rund um "Mobile and Communication" unglaublich spannend. Ich bin der Meinung, dass wir mit "Mobile Devices" nur noch ein paar Jahre von einem richtungsweisenden Entwicklungssprung entfernt sind. Die gegenwärtige Apps-Manie ist da nur ein kleines, aber wichtiges Rädchen. Dementsprechend ist Silverlight auch als ".NET-Technologie" mehr als ein kurzweiliges Vergnügen.

Im Web stellt man sich gerade zwei Herausforderungen. Einerseits ist es die clientseitige "User Experience", die mit JS-Libraries, HTML 5, Silverlight und mehr in Richtung "Rich-Internet-Applications" (RIA) zeigt. Das ist für Kreativgeister sicherlich ein spannendes Umfeld.

Andererseits versucht man sich neuerdings - ich muss seufzend sagen: endlich - ernsthaft mit dem Thema performante, instante, relevante und kontextbasierte Informationsgewinnung aus Massendaten zu beschäftigen. OData, Pivot, Twitter, Facebook, NoSql, CQRS, F#, Erlang. Endlich wird Informationsüberflutung nicht ignoriert, sondern mit Technologien kanalisiert. Ein wie ich finde hoch spannender und fordernder Technologiezweig.

Für angehende .NET-Entwickler im Enterprise-Umfeld sind sicherlich die WPF-Smart-Client-Technologien und das generelle Thema "Motional User Interfaces" wie zum Beispiel Surface oder ähnliches interessant. Hier wird es meiner Meinung nach in Zukunft eine deutlichere Wertschöpfung der Technologien geben.

Auch wurde in letzter Zeit schon deutlich, das der Schritt von "Motion" zu "Natural" nicht mehr weit ist. Augmented Reality - unabhängig vom Device - ist ein wichtiger Schritt, das Zusammenspiel von analoger und digitaler Welt harmonisch zu gestalten. Wo die Wii einen Anfang gemacht hat, begeht Microsoft mit Kinect entscheidende technologische Fortschritte. Gaming war schon immer ein Technologie-Treiber. Das fasziniert mich persönlich auch sehr an der Gaming-Technologie.

Nun ja, meine Empfehlungen sind nun Mal von meinen eigenen Präferenzen geprägt.

Golo Roden: Welchen Rat würdest Du einem Anfänger abschließend mit auf den Weg geben?

Ilker Cetinkaya: Puh, Du legst bei Deinen Fragen ganz schön viel Wert auf die Neulinge - schon die vierte "Anfänger-Frage" - sehr lobenswert. Ich weiß gar nicht so genau, ob ich einen Rat "nur für Anfänger" geben kann. Ich denke vielmehr, dass wir auch als "Erfahrene" uns immer wieder selbst Ratschläge geben können und sollten.

Damit möchte ich einen meiner Meinung nach wichtigen Punkt andeuten. Als Anfänger stellt man sich gerne - und natürlich auch berechtigt - in die Position des "Lernenden". Doch auch die langjährigen "Senior Software Developer" oder "Software Architekten" tragen dazu bei. Denn leider gilt oftmals noch "Hackordnung" und das "weise Wort" des Architekten hat ein größeres Gewicht als das des "Greenhorns".

Den Neulingen möchte ich folgendes auf den Weg geben: Versteckt Euch nicht und stellt Euch nicht unnötig unter den Scheffel. Denn ein "Erfahrener", der seinen Standpunkt als "Mastermind" transportiert oder seine Position oder Erfahrung als Entscheidungskriterium hervorhebt, ist keineswegs erfahren genug, um eine moderne, gemeinschaftliche Software-Entwicklung umzusetzen.

Weiterhin solltet Ihr euch bewusst sein, dass Ihr nicht alles lernen und können werdet. Software-Entwickler ist ein Beruf mit vielen Facetten und Möglichkeiten. Das bedeutet immer wieder lernen, immer wieder neu orientieren, immer wieder leisten und liefern. Das ist "Pflicht" und manchmal gar nicht so schwer. Aber das bedeutet auch, sich entfalten, sich einbringen, sich bilden, sich bestätigen, sich entwickeln. Das ist "Recht" und manchmal gar nicht so einfach.

Aber ein Rat ist meiner Meinung nach immer noch einer der wichtigsten, schönsten und besten:

Habt Spaß dabei!

Wie in meinem gestrigen Blogeintrag berichtet, war ich am 22. und 23. Juni 2010 in München auf den dotnetpro.powerdays, wobei ich für den Tag C# für Profis nicht nur als Referent, sondern auch als Content Manager tätig war.

Im Anschluss an diese beiden Tage habe ich noch einen Tag in München verbracht –unter anderem mit meinem neuen Beratungsformat, der tech:lounge – bevor es dann weiter nach Nürnberg ging, wo am 26. Juni 2010 der .NET Day Franken erstmalig stattgefunden hat.

Organisiert wurde diese eintägige Community-Konferenz von Thomas Müller und Bernd Hengelein, die als Themen .NET 4.0, Visual Studio 2010 und verteilte wie auch agile Entwicklung ausgewählt hatten.

Ich selbst war mit einer Session zu den Neuerungen in C# 4.0 unter dem Titel

C# 4.0 als Fliegenfalle

dabei, wobei mein Fokus nicht auf der Vorstellung der neuen Features lag, sondern auf der Frage, wann und in welchem Kontext diese sinnvoll eingesetzt werden sollten – im Prinzip angelehnt an meinen Blogeintrag Für und wider C# 4.0, allerdings um einiges ausführlicher.

Von den rund 100 Teilnehmern des .NET Day Franken durfte ich in meiner Session rund 60 begrüßen. Das Feedback war fast ausnahmslos sehr positiv, was mich natürlich sehr gefreut hat – erfreulich war auch, dass unter den von mir angesprochenen Kritikpunkten für die meisten Teilnehmer doch noch neue Aspekte enthalten waren, so dass das Ziel der Session erreicht wurde.

Alles in allem hat der .NET Day Franken sehr viel Spaß gemacht, es gab sehr viele interessante Sessions, ein hervorragendes Mittagsbuffet, eine schöne Lokation – was will man mehr.

Vor knapp drei Wochen veranstaltete die dotnetpro in München vier eintägige Events namens dotnetpro.powerday – jeweils einen zu C#, O/R-Mapping, Windows Azure und Parallelprogrammierung.

Für den ersten der vier Tage, der unter dem Titel C# für Profis veranstaltet wurde, war ich nicht nur als Referent tätig, sondern auch als Content Manager. Meine Aufgabe war also, die Agenda zusammenzustellen und die Referenten auszuwählen.

Gemeinsam mit David Tielke und Albert Weinert wurden eine Keynote, vier Sessions und eine Abschlussdiskussion gehalten – wobei wir jeden ´für Auftritt mit Ausnahme der Keynote zu zweit auf der Bühne standen. Dies wirkte auf die Teilnehmer zwar zunächst ungewohnt, brachte aber auch mehr Leben und Interaktion auf die Bühne – was den anspruchsvollen Themen zu Gute kam.

Nach einem Überblick über die bisherige Historie von C#, die jeweiligen Schwerpunkte der einzelnen Versionen und die mögliche zukünftige Entwicklung in der Keynote haben sich die einzelnen Sessions mit dediziert ausgewählten Themen beschäftigt:

• Zunächst wurde das Typsystem samt generischen Typen mit den entsprechenden Besonderheiten unter die Lupe genommen. Dazu zählten neben den Grundlagen wie Werte- und Referenztypen vor allem Interna des Typsystems, die Arbeitsweise und Wirkung der Garbage Collection und spezielle Typen wie beispielsweise dem Nulltyp und Schlüsselwörtern wie yield.
• Danach ging es um Delegaten und Ereignisse – wie diese intern aufgebaut sind, was der Unterschied zwischen der Feld- und der Eigenschaftensyntax bei Ereignissen ist, wie Threading in diesem Zusammenhang funktioniert und ähnliche Themen.
• Nach der Mittagspause waren die funktionalen und dynamischen Erweiterungen von C# 3.0 und 4.0 Gesprächsthema. Insbesondere wurde hierbei auf die zahlreichen neuen Möglichkeiten in Verbindung mit COM und der DLR eingegangen, wobei auch eine kritische Betrachtung der neuen Features nicht fehlen durfte.
• Den krönenden Abschluss bildete das Thema LINQ, wobei zunächst alle dazu gehörigen Sprachelemente beleuchtet wurden, bevor es an deren Zusammenspiel und die dabei geltenden Besonderheiten wie verzögerte Ausführung und die Schnittstellen IEnumerable<T> und IQueryable<T> ging.

Im Rahmen der Abschlussdiskussion haben wir schließlich noch ein kleines Quiz zu C# veranstaltet, bei dem es einige sehr schöne Preise wie unter anderem Lizenzen für Resharper zu gewinnen gab.

Insgesamt durften wir rund 60 Teilnehmer begrüßen, denen der Tag – dem direkten Feedback und den ausgefüllten Feedbackbögen nach zu urteilen – sehr gut gefallen und einiges Neues vermittelt hat.

Auch mir persönlich hat der Tag sehr viel Spaß gemacht, weshalb ich mich an dieser Stelle auch noch einmal bei den Teilnehmern bedanken möchte – ohne Euch wäre dieser Tag so nicht möglich gewesen!

Nachdem ich mich in der jüngeren Vergangenheit eher mit Scrum denn mit Extreme Programming (XP) beschäftigt habe, war nun wieder ein Buch zu XP an der Reihe – sogar eines, das sich dediziert mit Extreme Programming in Verbindung mit der .NET-Plattform beschäftigt: eXtreme .NET von Dr. Neil Roodyn.

Nach einer kurzen Einführung in die Thematik von XP beschäftigt sich das Buch in jedem Kapitel mit einer ausgewählten agilen Praktik und erläutert diese in der Theorie. Außerdem werden typische Real-World-Szenarien exemplarisch in einem fiktiven Team durchgespielt – was teilweise zwar ein wenig gestellt wirkt, dennoch aber einige gute Punkte thematisiert.

Besonders interessant wird das Buch dadurch, dass in jedem Kapitel zahlreiche Aufgaben zu der jeweiligen Praktik gestellt werden, die mit .NET und verwandten Technologien wie beispielsweise NUnit zu lösen sind.

Da eXtreme .NET bereits aus dem Jahr 2005 stammt, basieren die Beispiele zwar noch auf .NET 1.1, weshalb die Syntax teilweise etwas umständlich wirkt – dem Lerneffekt hinsichtlich agiler Methoden und XP tut dies jedoch keinen Abbruch.

Auf diese Art werden die agilen Praktiken Programmieren in Paaren, testgetriebene Entwicklung (TDD), Refaktorisieren, Spiking und kontinuierliche Integration vorgestellt und gelehrt, wobei auf testgetriebene Entwicklung besonders großen Wert gelegt wird – als einzigem Thema werden TDD zwei Kapitel zugestanden.

Abgerundet wird dieses Themenspektrum durch ein Kapitel, das sich mit der Frage beschäftigt, wie große Probleme in kleinere zerteilt werden können, und durch das abschließende Kapitel, das alle Praktiken wie auch deren Zusammenspiel in einem gemeinsamen größeren Rahmen präsentiert.

eXtreme .NET birgt für Entwickler, die sich bereits mit XP beschäftigt haben oder ein anderes Buch zu diesem Thema wie beispielsweise eXtreme Programming von Henning Wolf, Stefan Roock und Martin Lippert gelesen haben, wenig neues – für Entwickler, die auf Basis von .NET arbeiten und einen praxisnahen ersten Einstieg wagen wollen, bietet es aber eine gute Grundlage.

Da allerdings nicht alle Praktiken aus XP angesprochen werden – der Einsatz von Programmierrichtlinien, gemeinsame Verantwortlichkeit oder nachhaltiges Tempo fehlen beispielsweise – ersetzt das Buch auch nicht die Lektüre eines weitergehenden Buches.

Kurzum: Kurzweilige Lektüre für XP-Neulinge, bei der man sich aber eine neue Auflage wünschen würde, die zum einen auf einer moderneren Version von .NET basiert, und die zum anderen alle Praktiken aus XP abdeckt.

Stefan Lieser ist freiberuflicher Berater, Trainer und Autor aus Leidenschaft. Sein Interesse gilt den agilen Methoden der Softwareentwicklung, und er sucht ständig nach Verbesserungen und neuen Wegen. Mit Ralf Westphal hat er die Clean Code Developer-Initiative ins Leben gerufen. Durch seinen Fokus auf Clean Code Developer ist er ferner als Berater in Brownfield-Projekten tätig. Sie erreichen ihn über seine Webseite.

Golo Roden: Stefan, wie bist Du zur Softwareentwicklung gekommen? Wie und wann hast Du angefangen?

Stefan Lieser: Ich habe als Schüler in den Ferien als Datenerfasser in einem Pharmabetrieb gejobbt. Mein Vater hat im gleichen Betrieb gearbeitet und mir den Job besorgt. Tatsächlich habe ich sogar mit ihm in einem Büro gesessen, was eine einmalige Chance war. Denn wer erhält als Jugendlicher schon einen tieferen Einblick in den Beruf der Eltern? Jedenfalls, wenn man mal von handwerklichen Berufen absieht.

Meine Aufgabe war die Erfassung von Fragebögen zu klinischen Studien. Die Abteilung hatte die Aufgabe, diverse Statistiken zu den Daten zu berechnen, Diagramme zu erstellen, ... Dabei fielen immer wieder kleinere Programmieraufgaben an, so habe ich begonnen, in FORTRAN zu programmieren. Das war vor der Zeit der PCs, es gab keine grafische Oberfläche, sondern green-screen-Terminals an einer DEC PDP-11 und später einer MicroVAX.

Nach dem Abitur habe ich Zivildienst gemacht, bin von zu Hause ausgezogen und habe meinen ersten PC gekauft. In der Zeit habe ich jede freie Minute am Rechner gehockt und C, Assembler sowie Turbo Pascal gelernt. Nach dem Zivildienst habe ich in Koblenz Informatik studiert und auch in dieser Zeit ständig Software entwickelt. Hier gesellten sich C++ und Modula-2 hinzu. Mit der Softwareentwicklung habe ich mir mein Studium finanziert. Nach dem Studium habe ich mit zwei Partnern die S&L Netzwerktechnik GmbH gegründet und war 5 Jahre lang Netzwerker. Das war auch schön, aber die Softwareentwicklung liegt mir mehr am Herzen.

So habe ich dann erst als angestellter Entwickler gearbeitet und mich dann erneut selbständig gemacht. Heute arbeite ich als Trainer, Berater und Autor im Bereich Clean Code Developer und Brownfield. Das scheinen auf den ersten Blick zwei Bereiche zu sein, die nichts gemeinsam haben. Brownfield steht quasi am einen Ende der Skala, Clean Code am anderen. Doch die wenigsten Entwickler kommen in den Genuss, in sogenannten Greenfield Projekten "auf der grünen Wiese" anzufangen. Viel häufiger existiert ein Projekt bereits lange Zeit und die Frage lautet, wie schafft man es, dessen innere Qualität zu verbessern.

Golo Roden: Gemeinsam mit Ralf Westphal hast Du die Initiative "Clean Code Developer" ins Leben gerufen. Welche Bedeutung misst Du diesem Thema bereits für Anfänger bei?

Stefan Lieser: Die Clean Code Developer-Initiative soll ein Gegengewicht sein, um zwei Sichtweisen ins Gleichgewicht zu bringen. Wir haben in der Branche schon lange den Fokus auf König Kunde. Dies ist total in Ordnung, aber es fehlt die Sichtweise derjenigen, die sozusagen unter die Haube schauen. Wird die Entwicklung nur davon geleitet, Kundenwünsche umzusetzen, dann fehlt die Perspektive der Softwareentwickler.

Unsere Kunden gehen beispielsweise völlig zu Recht davon aus, dass sie Software erhalten, die immer weiterentwickelt werden kann. Ob sie sich heute ein neues Feature wünschen oder dasselbe Feature erst in einem Jahr entwickeln lassen, sie gehen davon aus, dass es einen fixen Preis hat. Heute ist es jedoch so, dass der Preis für das Feature dramatisch ansteigt, je später es ergänzt werden soll. Das liegt daran, dass nicht ausreichend auf die innere Qualität der Software geachtet wird.

Evolvierbarkeit fällt nicht einfach vom Himmel, sondern muss von den Softwareentwicklern von Anfang an bedacht und umgesetzt werden. Insofern bin ich sehr dafür, dass angehende Softwareentwickler sich von Anfang an in ihrer Ausbildung mit den Bausteinen und Werten der Clean Code Developer-Initiative auseinandersetzen. Wir versuchen daher, mit Ausbildungsstätten in Kontakt zu treten. Ab und zu gelingt dies schon und wir halten Vorträge über die Initiative an Hochschulen oder ähnliches. In der allgemeinen Lehre sehen wir die Inhalte allerdings noch zu selten.

Golo Roden: Ein wesentliches Merkmal der IT ist, dass man beständig mit neuen Entwicklungen konfrontriert wird, und diesen folgen muss. Woher nimmst Du die Motivation, Dich quasi jeden Tag weiterzubilden und mit Neuem zu beschäftigen?

Stefan Lieser: Einerseits ist da die Neugierde, die mich antreibt, mich mit Neuem auseinanderzusetzen. Andererseits blende ich bewusst einiges aus. Vor allem den ständigen technischen Neuerungen renne ich nicht mehr so hinterher, wie ich das früher getan habe.

Dem liegt die Erkenntnis zugrunde, dass Prinzipien und Praktiken der Softwareentwicklung in der Regel deutlich länger Bestand haben als diverse Technologien. Das soll nun nicht heißen, dass ich Technologie für unnötig erachte. Aber ich meine schon, dass man sich auch mal getrost zurücklehnen kann, um eine Technologie nicht als erster einzusetzen. Am Ende fehlt mir selten die Motivation, mich mit Neuem zu befassen.

Für mich liegt die Herausforderung eher darin, meinen eigenen "roten Faden" zu finden und an dem dann beständig weiterzuarbeiten. Fokus ist wichtig. Nicht nur bei der Softwareentwicklung, auch bei der persönlichen Entwicklung. Und regelmäßige Reflektion, um festzustellen, ob das, was man tut, das richtige ist.

Golo Roden: Wenn sich ein Anfänger heute mit dem Thema Softwareentwicklung befassen will - welche Voraussetzungen sollte er Deiner Meinung nach dafür mitbringen, und was siehst Du als No-Go an?

Stefan Lieser: Eine wichtige Voraussetzung im Bereich Softwareentwicklung ist die Fähigkeit, zu abstrahieren. Wer damit Schwierigkeiten hat, scheint mir ungeeignet für eine Tätigkeit im Bereich Softwareentwicklung. Damit meine ich nicht, dass man diese Fähigkeit entweder hat oder nicht hat. Natürlich kann man seine Fähigkeiten, zu abstrahieren, weiterentwickeln. Erstaunlicherweise macht das aber vielen Entwicklern große Probleme. Die regelmäßig Reflektion darüber, wie ich an Problemstellungen herangehe und was dann auf dem Weg zur Lösung so alles passiert, ist eine wichtige, wenn nicht sogar die wichtigste Praktik zur Weiterentwicklung.

Damit gehört die Bereitschaft, alles zu hinterfragen und ständig nach neuen Wegen zu suchen, für mich zu einem Beruf in der Softwareentwicklung dazu. Es gibt vermutlich keinen Beruf mehr, den man einmal lernt und dann nur noch ausübt. Aber speziell die Softwareentwicklung lebt von der beständigen Weiterentwicklung. Die Bereitschaft, in diesem Beruf ständig zu lernen, sollte man also mitbringen.

Golo Roden: Bei der Vielzahl an Technologien, die es heute gibt: Womit sollte ein Anfänger heutzutage anfangen?

Stefan Lieser: Ich habe es oben schon angedeutet, Technologien sind überbewertet. Eine Empfehlung für eine bestimmte Technologie muss in einem Kontext stehen. Wenn die Frage lautet, welche Technologie ich empfehlen würde, um als Softwareentwickler einen Job zu finden, würde ich vielleicht "Java" antworten. Das ist aber vermutlich nicht die Antwort, die Du hören möchtest. Aber auch im Bereich .NET kann ich keine solche Empfehlung aussprechen, ohne die Frage in einen Kontext einzubetten. Ich will mich aber nicht vor einer Antwort drücken und daher zwei Dinge empfehlen.

Wie ich weiter oben schon erwähnt habe, halte ich im Bereich Softwareentwicklung Werte, Prinzipien und Praktiken für elementar. Denn diese ermöglichen mir eine Bewertung der zur Verfügung stehenden Technologien. Meine erste Empfehlung lautet also, befasst euch mit den Werten der Clean Code Developer-Initiative.

Die zweite Empfehlung lautet, nicht nur auf Microsoft zu schauen. Natürlich bringt Microsoft eine ganze Reihe hervorragender Technologien hervor. Aber andere Mütter haben auch schöne Töchter. Gerade im Open Source-Bereich gibt es eine ganze Reihe an Technologien, die von vielen Entwicklern nicht beachtet werden, weil sie nicht von Microsoft stammen. Ein Blick über den Tellerrand schadet nicht.

Golo Roden: Welchen Rat würdest Du einem Anfänger abschließend mit auf den Weg geben?

Stefan Lieser: Musiker üben. Sie stehen nicht nur auf der Bühne und "performen", sondern die meiste Zeit üben sie. Softwareentwickler scheinen zu glauben, sie könnten einfach so "performen". Immer. Ohne zu üben. Problematisch daran ist, dass Auftritt und Übung unterschiedliche Anforderungen stellen. Es sind sozusagen zwei völlig andere "Betriebsarten". Beim Auftritt sollte man Fehler tunlichst vermeiden, während man beim Üben eine Umgebung braucht, die Fehler toleriert, um sich weiterzuentwickeln.

Da stellt sich dann die Frage, wie man sich als Softwareentwickler weiterentwickeln kann, wenn man nur in der Betriebsart "keinen Fehler machen" arbeitet. Mein Rat, nicht nur an Anfänger, lautet daher: Regelmäßig üben! Ob man sich dafür jeden Tag einen Zeitrahmen einräumt oder einmal pro Woche, ist eine Frage des Umfeldes. Die Regelmäßigkeit ist es, was zählt. Im Web und in Fachzeitschriften wie der dotnetpro findet man genügend große und kleine Übungen. Daran sollte man seine Fähigkeiten als Softwareentwickler weiter entwickeln.

Nachdem ich vor einigen Monaten das ausgesprochen lesenswerte Buch Geschichten vom Scrum von Holger Koschek gelesen habe, habe ich mir in den vergangenen Tagen Agile Softwareentwicklung mit verteilten Teams von Jutta Eckstein als Lektüre vorgenommen.

Der Beschreibung nach richtet sich das Buch an

Entwickler und Manager, die auch in einer verteilten Umgebung die Vorteile agiler Entwicklung nutzen

möchten. Als Basis dient dem Buch dabei das Agile Manifest, auf das im Verlauf immer wieder Bezug genommen wird.

Agile Softwareentwicklung mit verteilten Teams führt als Grundlage zudem den Begriff des Featureteams ein, wobei ein solches derart definiert wird, dass ein Team nicht an Hand technischer Kompetenzen, sondern an Hand gemeinsam bearbeiteter Features domänenübergreifend gebildet wird.

Ausführlich beschreibt Jutta Eckstein im weiteren Verlauf dann, wie die Kommunikation von verteilten und verstreuten Teams gewährleistet werden kann, worauf dabei geachtet werden muss, und welche gemeinsame Infrastruktur erforderlich ist.

Zudem werden einige Praktiken aus dem Extreme Programming angesprochen, die für den erfolgreichen Einsatz im Rahmen von verteilter Entwicklung adaptiert werden müssen – wie beispielsweise Pair Programming und Collective Code Ownership.

Vieles von dem, was in dem Buch beschrieben wird, ist nachvollziehbar und entspricht letztlich naheliegenden und logischen Ideen, angewandt auf agile Methoden.

Einige Themen werden jedoch meines Erachtens überbewertet – so wird beispielsweise wiederholt darauf hingewiesen, wie wichtig es sei, über verschiedene Kontinente verteilte Teams regelmäßig vollständig zueinander zu bringen, um das Gemeinschaftsgefühl zu stärken.

Die Erfüllung dieses Vorschlags mag wünschenswert sein – in der Praxis ist dies jedoch absolut unrealistisch, da es schlicht und ergreifend zu teuer und zeitlich nicht möglich ist, alle paar Wochen komplette Teams zwischen verschiedenen Kontinenten hin- und herfliegen zu lassen.

Außerdem gibt es Themen, die das Buch höchstens anschneidet, im Großen und Ganzen aber ignoriert: So wird die Problematik von Teams, die sich in verschiedenen Zeitzonen befinden, zwar angesprochen und somit als existent anerkannt – wirkliche Lösungsvorschläge hierfür finden sich allerdings kaum bis gar nicht.

Alles in allem ist Agile Softwareentwicklung mit verteilten Teams damit vor allem zu lang – 240 Seiten sind schlichtweg zu viel für die wenigen nicht-naheliegenden Ideen, die vermittelt werden.

Außerdem fällt die schlechte Grammatik der Autorin sehr negativ auf – an zahlreichen Stellen fehlen Kommata, was den Lesefluss erheblich stört, da man auf diese Art etliche Sätze mehr als ein Mal lesen muss, um ihre eigentliche Bedeutung zu erfassen.

Kurzum: Die übrigen Bücher zu agilen Methoden aus dem dpunkt.verlag wie Extreme Programming oder Geschichten von Scrum sind bedeutend besser – auf weniger Seiten vermitteln sie mehr konkretes Wissen, sind fehlerfrei und nicht dermaßen trocken geschrieben und lesen sich insgesamt flüssiger.

Jeder, der sich mit der Konzeption und der Entwicklung von Software beschäftigt, kennt das Problem: Man ist so sehr in das Projekt oder den zu schreibenden Code vertieft, dass es nicht gelingt, die notwendige kritische Distanz zu bewahren, um Denkfehler frühzeitig aufdecken und Sackgassen vermeiden zu können.

Da Softwareentwicklung als Prozess selten nach außen kommuniziert wird, kommt Hilfe häufig spät oder gar zu spät – denn in der Regel wird erst dann um Hilfe gebeten, wenn das Kind schon in den Brunnen gefallen ist. Was fehlt, ist ein geeigneter, unabhängiger Sparringspartner, der eine zweite Sicht und einen anderen Standpunkt einbringen kann.

Deshalb biete ich am 25. Juni 2010 in München und am 28. Juni 2010 in Köln ebendies an: An beiden Tagen bin ich jeweils von 9 bis 17 Uhr in einem Café und setze mich mit Entwicklern, Architekten, Team- und Projektleitern zusammen, um deren Probleme zu besprechen und gemeinsam zu versuchen, nach bestem Wissen und Gewissen einen geeigneten Lösungsansatz zu finden – kostenlos, wobei ich gegen eine Einladung auf eine Cola nichts einzuwenden habe.

Thematisch wird es sich dabei um .NET, Codequalität und agile Methoden drehen: Ob es dabei um die Planung, die Architektur, die konkrete Entwicklung oder den Prozess geht, ob die Fragen eher genereller oder eher spezieller Natur sind, spielt keine Rolle – das entscheiden Sie, je nachdem, was Sie mitbringen!

Damit verschiedene Interessenten die Gelegenheit erhalten, sich mit mir zu besprechen, ist eine Sitzung auf 90 Minuten begrenzt – wobei sich in 90 Minuten häufig deutlich mehr besprechen lässt, als man zunächst vermuten würde: Wichtig ist nur, dass Sie das zu besprechende Thema in kompakter, aber vollständiger Form mitbringen, so dass mir genug Zeit bleibt, mich hineinzudenken.

Aus diesem Grund möchte ich auch darum bitten, dass sich Interessenten vorher bei mir per E-Mail anmelden – auch um auszuschließen, dass ich zu einem Thema nichts beitragen kann oder dass sich mehrere Interessenten zeitlich überschneiden, um die Diskretion zu wahren: Eine Sitzung ist also nicht öffentlich zugänglich für interessierte Zuhörer.

Wenn dieses Angebot Ihr Interesse geweckt hat, finden Sie abschließend noch die Termine und Lokationen im Überblick:

• München, 25. Juni 2010, 9 bis 17 Uhr, Forum Café
• Köln, 28. Juni 2010, 9 bis 17 Uhr, Café Feynsinn

Ich freue mich auf spannende Themen und interessante Diskussionen!

Foundations for Professionals – unter diesem Titel biete ich zukünftig Schulungen zu den Themen .NET, Codequalität und agile Methoden an. Das Konzept:

Fundiertes Wissen, akkurat und mit Liebe zum Detail aufbereitet, für alle Entwickler und Architekten, die Softwareentwicklung als ihre Berufung ansehen, der sie auf professionelle Art und mit Leidenschaft nachgehen.

Den Anfang macht vom 15. bis 17. September 2010 eine dreitägige Schulung zum Thema Extreme Programming (XP), in der so wohl theoretisch wie auch praktisch die Werte und Praktiken dieser agilen Methode vermittelt werden.

Veranstaltungsort ist das Vier-Sterne-Hotel Windenreuter Hof in Emmendingen, das in schönster Panoramalage mit Blick auf den Kaiserstuhl, den Breisgau und die Vogesen liegt und eine ruhige und konzentrierte Schulungsatmosphäre in modern ausgestatteten Tagungsräumen ermöglicht.

Die Agenda umfasst derzeit die folgenden Themen:

• Teambuilding und Setup
• XP aus 10.000 Meter Höhe
• Agile Anforderungen
• Planen, schätzen und messen
• Design und Code
• Entwickler vs Team
• Testen, testen, testen, …
• Review und Retrospektive
• XP im Rahmen von Scrum
• Die Scrum-Stunde
• … und wie weiter?

Die Schulung richtet sich an Entwickler, Architekten wie auch Team- und Projektleiter, unabhängig von der zur Entwicklung verwendeten technischen Plattform.

Um dem Ziel, fundiertes Wissen akkurat und mit Liebe zum Detail zu vermitteln, gerecht zu werden, bedarf es einer persönlichen Atmosphäre, in der jeder Teilnehmer intensiv und individuell geschult werden kann. Daher ist die Teilnehmerzahl auf 10 begrenzt.

Da die Schulung einschließlich Übernachtung und Verpflegung als all-inclusive angeboten wird, wird den einzelnen Teilnehmern die Gelegenheit geboten, auch abseits der Schulung ihre Gedanken auszutauschen und miteinander zu diskutieren – und sich bei Bedarf auch zurückziehen und entspannen zu können.

Für die ersten fünf angemeldeten Teilnehmer gilt der ermäßigte Early-Bird-Preis pro Person von 1.799 Euro zuzüglich Umsatzsteuer, für alle weiteren Teilnehmer gilt der reguläre Preis pro Person von 1.999 Euro zuzüglich Umsatzsteuer.