Viele Softwareprojekte sprengen ihren Zeit- und Finanzrahmen, obwohl (oder gerade weil?) ausführlich Pläne gemacht wurden, und manchmal ist das Endresultat sogar nur die ausgefeilte Dokumentation für das nicht implementierte Design. Agile Methodologien [Agil], unter ihnen unser Favorit Extremes Programmieren (XP), wenden sich gegen solche streng formalisierten Vorgehensweisen. Die Hauptzutaten für XP sind im Wesentlichen die best practices, die erfolgreiche Programmierer seit Jahrzehnten einsetzen. Ihre Anwendung wird hier allerdings ins Extrem gesteigert, wodurch einige Praktiken entstehen, die bei Außenstehenden erst einmal Verwunderung auslösen.

Kent Beck gilt als der Gründer von XP (Das Kürzel XP war in der Programmierergemeinde übrigens schon lange in Gebrauch, bevor es von Microsoft für die eXPerience seines neuen Betriebssystems gekapert wurde. Eine weitere Anwendung findet XP übrigens in der Luftfahrt: als eXperimental Planes werden Prototypen bezeichnet, deren Daseinszweck darin besteht, die Flugtauglichkeit des Zusammenbaus zu testen, nachdem eine ausreichende Belastbarkeit der einzelnen Komponenten gesichert ist ...). Die erste Bewährungsprobe erlebte diese Methodologie, als mit ihrer Hilfe bei Chrysler ein verfahrenes Lohnberechnungsprojekt zu einem erfolgreichen Abschluss gebracht wurde.

Vier Werte
Im Kern beruht XP auf vier Werten:

• Kommunikation muss zwischen allen Beteiligten und möglichst unmittelbar möglich sein. Daher gibt es einen gemeinsamen Arbeitsraum, in dem sich auch ein Repräsentant des Nutzers für Rückfragen aufhält.
• Einfachheit: Beschränkung auf die einfachste mögliche Lösung, die nichts vorweg nimmt und keinen doppelten Code enthält. Kernighan und Plauger haben das mit Sag, was du meinst, einfach und direkt. umschrieben.
• Feedback: Möglichst schneller und häufiger Erfahrungsaustausch mit Anwendern und dem Code, um Probleme so früh wie möglich kennenzulernen. Dies beginnt mit kontinuierlichem Unit-Testing und endet in häufigen Releases, die vom Kunden jederzeit eingesetzt werden können.
• Mut: wenn nötig, wird vorhandener Code geändert, wenn es sein muss, auch radikal.

Einfachheit ist Trumpf
Die Betonung einfacher und schnell realisierbarer Lösungen sorgt dafür, dass dem Kunden schnell funktionierende Software präsentiert werden kann, mit der er bereits Erfahrungen sammeln kann, während die Entwicklung des übrigen Systems noch fortschreitet. Seine Rückmeldungen fließen unmittelbar in die weitere Entwicklung ein, sodass zu praktisch jeder Zeit eine funktionierende Software vorhanden ist.
Gleichzeitig bleibt das System so überschaubar wie möglich, was wiederum seine Erweiterung begünstigt. Dabei erwartet ein XP-Team, dass sich im Laufe der Entwicklung die Anforderungen seitens des Kunden ändern. Auch tiefgreifende Änderungen der Prioritäten und Anforderungen können ohne Verluste realisiert werden, da im Code keine Vorleistungen auf Verdacht getroffen werden. Nur das, was aktuell wirklich gebraucht wird, wird auch programmiert.

XP prinzipiell
Wir wollen die XP-Methode an einem einfachen Beispiel erläutern. Der Auftraggeber stellt einen Repräsentanten, den Kunden, der entscheiden kann und muss, welche Features in welcher Reihenfolge zu implementieren sind. Dieser Kunde ist für die Programmierer immer zu sprechen, damit auftretende Probleme sofort gelöst werden können.

Der Kunde bestimmt, wie sein Geld ausgegeben wird
Bei der anfänglichen Planung teilen Kunde und Programmierer das Projekt in handhabbare Teile auf, die für sich genommen jeweils brauchbar sind, mithin einen wirklichen Gegenwert für das bezahlte Honorar bieten. Diese User Stories werden auf Karteikarten notiert, um während der folgenden Phase schnell auf verschiedene Arten angeordnet und umsortiert werden zu können. Der Kunde legt die aktuellen Prioritäten der Stories fest und bestimmt Akzeptanztests für deren Abnahme.
Die Programmierer schätzen (bzw. wissen nach einiger Zeit), wie viel Arbeit sie in der anstehenden Iteration erledigen können. Sie bestimmen damit, wie viele der sortierten Stories in den nächsten Wochen bearbeitet werden.
Bereits an dieser Stelle wird deutlich, wie vernünftig der XP-Ansatz ist: Der Kunde sagt, was er haben möchte; der Programmierer sagt, wie lange es dauert; vermutlich sagt dann der Kunde, dass er doch etwas anderes haben möchte, weil die neue Kombination für ihn wertvoller ist. Wesentlich ist die Aufteilung der Verantwortung und der Respekt vor den Entscheidungen des Partners: Der Kunde trifft geschäftlich orientierte Entscheidungen, der Programmierer technische.
Wenn festgelegt ist, welche User Stories bearbeitet werden sollen, werden sie in Aufgaben untergliedert, für die wiederum einzelne Programmierer verantwortlich zeichnen.
Die Programmierung selbst erfolgt aber immer in Paaren: Zwei Personen arbeiten an einem Computer. Diese Paarungen wechseln ab, je nachdem, wer beim aktuellen Task gerade besonders hilfreich sein kann. So wird Expertenwissen sehr schnell im Team verbreitet, was sich auf Arbeitseinstellung und Stabilität (Ausscheiden, Krankheit, etc.) des Teams positiv auswirkt.
Das paarweise Arbeiten fördert die Konzentration auf die anstehende Aufgabe und verhindert, dass ein Programmierer den Wald vor lauter Bäumen aus den Augen verliert. Es ist nämlich eine der wesentlichen Aufgaben des Beifahrers, dafür zu sorgen, dass der Fahrer nicht vom Weg abkommt. Im Endeffekt wird ein kontinuierlicher Review-Prozess für den entstehenden Code realisiert.
Dazu gehört auch, die Menschen, die für das Gelingen des Projekts nötig sind, nicht zu überfordern. Überstunden sind in XP-Teams verpönt, denn ihr scheinbarer Geschwindigkeitsvorteil wird durch die höhere Fehlerquote müder Programmierer schnell wieder zunichte gemacht.
Wenn sich die Programmierer verschätzt haben und eine Aufgabe mehr Zeit in Anspruch nimmt als vorgesehen, ist das kein Beinbruch. Zum einen wird das Team in der nächsten Iteration weniger neue User Stories annehmen, zum anderen erhält der Kunde schnell die Information, dass er möglicherweise die Prioritätenliste umstellen muss, um beim Projektende ein möglichst gut einsetzbares System zu erhalten.
Jedoch sind solche drastischen Maßnahmen oft nicht notwendig, da in einem XP-Team ein Tracker dafür zuständig ist, das plangerechte Fortschreiten der Arbeiten zu überwachen. Sollten Abweichungen auftreten, kann das Team in der Regel intern Kapazitäten umschichten, sodass das gesteckte Etappenziel doch noch erreicht wird. Die Ergebnisse der aktuellen Iteration dienen dann als Entscheidungsgrundlage für die Verhandlungsphase der nächsten Entwicklungsrunde.
Die ständige Anwesenheit des Kunden ist für beide Seiten von großem Nutzen. Während sich durch die genaue Analyse manchmal für den Kunden neue Wege eröffnen, seine Geschäftsprozesse zu strukturieren, können sich durch externe Einflüsse die Geschäftsbedingungen von heute auf morgen ändern. Während hier bei einem Wasserfall-Produkt oft monatelange Planung verschwendet wird, ist der Schaden in einem XP-Projekt meist nur gering.

Implementierungstechniken
Der Mut, notwendige Änderungen am Code vorzunehmen, kommt nicht von ungefähr. Für jede Methode, die im System verwendet wird, gibt es Unit-Tests, mit denen ihr Verhalten (nicht nur in Ausnahmefällen) bestimmt wird. Nur wenn alle Unit-Tests laufen, darf der Code von einer Entwicklungsmaschine in das allgemeine Repository übernommen werden.
Unit-Tests ermöglichen also die konsequente Durchführung einer wesentlichen Technik zur Verbesserung der Softwarequalität: beim Refaktorieren geht es darum, unter Beibehaltung der Funktonalität die Struktur des Codes zu verbessern. Wenn alle Unit-Tests vor und nach dem Refaktorieren laufen, wird das System als Ganzes funktionieren, wobei es auf einem stabileren Fundament ruht und ausbaufähiger geworden ist.

XP-gemäße Vertragsgestaltung
XP geht davon aus, dass von den vier Plangrößen Zeit, Umfang, Ressourcen und Qualität niemals alle frei gewählt werden können, denn sonst würde ein kostenloser Programmierer gestern die ultimative Software erzeugt haben. Da typischerweise mit einem bestimmten Team in einer bestimmten Zeit ein zuverlässiges Programm entwickelt werden soll, bleibt als einzige Veränderliche der Umfang des Produkts übrig [OSC].
Diese etwas absonderlich anmutende Folgerung ist bei näherer Betrachtung verlockend. Wer würde nicht auf ein abstruses Feature verzichten, wenn dafür der Rest des Systems fehlerfrei läuft?

Vergleich mit Open Source
Open Source ist eigentlich eine Distributionsform, kein Entwicklungsprozess. Bei genauerem Hinsehen finden sich mehrere Parallelen zwischen XP und Open Source-Programmen: die andauernde Integration (nightly builds) und viele inkrementelle Releases. Einige Projekte setzen auch auf Test Suites. Die bekannteren sind wohl gcc, Perl und Ruby, die alle mit ausführlichen Test Suites kommen. Ebenso sind auf Mailinglisten oder in Newsgruppen Kunden und Programmierer in ständigem Kontakt.
Die Hauptunterschiede liegen in den Details der Zeit- und Entfernungsspannen und weniger im Prinzip.
Open Source-Projekte stellen oft neben ihren offiziellen Releases so genannte Snapshots zur Verfügung, die regelmäßig automatisch erstellt werden. So kann ein risikobereiter Nutzer bei einem dringend benötigten Programm darauf hoffen, dass ein kritischer Fehler schon behoben ist und dass sich andererseits keine neuen Fehler eingeschlichen haben. Im XP-Prozess sind die Releasezyklen ebenfalls kurz, Zwischenupdates kommen aber von Haus aus nicht vor. Idealerweise würde die Behandlung eines Fehlers so aussehen, dass daraus eine weitere User Story gemacht wird, die bei der nächsten Release- oder Iterationsplanung mit verhandelt wird.
Deutlicher werden die Unterschiede bei Test Suites. Die meisten Open Source-Projekte dürften wohl auf die herkömmliche Art entstanden sein. Der Programmierer schreibt einige Funktionen und überprüft dann ihre Funktion, unter Umständen durch längere Sitzungen im Debugger. XP schreibt dagegen vor, dass Test First programmiert wird, das heißt, die Unit-Tests werden geschrieben, bevor die eigentliche Funktion entsteht. Durch die Tests wird der Funktionsumfang vorgegeben, sodass der Programmierer weiß, wann er genug gearbeitet hat: Wenn alle Tests funktionieren, ist die Funktion komplex genug, alle Anforderungen zu erfüllen, andererseits so einfach wie möglich. Diese Methode hat Auswirkungen auf das Design, sie schafft klarere Strukturen. Viele der Design Patterns entstehen so von selbst.
Die Tests der meisten Open Source-Projekte würden im XP-Jargon als Akzeptanztests bezeichnet, sie sichern die Funktion im Großen. Die Unit-Tests dagegen sichern die Funktion im Kleinen, indem sie alles das überprüfen, was schief gehen kann. Auf der XP-Mailingliste ist schon mehrfach von Projekten berichtet worden, bei denen der Anteil von Tests an der gesamten Codebasis zwischen 30 und 40 Prozent lag.
Der Kontakt zwischen Kunde und Programmierer ist bei XP-Projekten auch strenger geregelt: Es gibt nur einen Kunden (on Site), der stellvertretend für alle Nutzer spricht. So werden interne Differenzen und widersprüchliche Wünsche schon ausdiskutiert, bevor sie an die Entwickler herangetragen werden. Ein Blick in die Mailinglisten von Open Source-Projekten zeigt dagegen, dass das dort praktizierte Entwicklungsmodell zu Recht den Namen Bazaar trägt: Ein beträchtlicher Anteil der Kommunikation zwischen Programmierer und Nutzer geht darum, die unterschiedlichen Kundenwünsche unter einen Hut zu bringen.
Wenn bei Open Source-Programmen ein Fehler auftaucht, wird er oft behoben, indem der Kunde den Fehler isoliert, vielleicht sogar selbst einen Vorschlag zur Korrektur macht. Oft schließt sich daran eine kleine Diskussion an, bis ein Bugfix gefunden ist, der mit dem Rest des Programms verträglich ist. Dieses conversational Programming ist zwar dynamisch und schöpft aus zwei Quellen, hält aber einem Vergleich mit paarweisem Programmieren nicht stand. Der wesentliche Code wird in Einzelarbeit geschaffen, während bei XP von Anfang an stets zwei Personen beteiligt sind, die sich gegenseitig kontrollieren und dafür sorgen können, dass die Grundregeln eingehalten werden.
Bei den meisten Open Source-Projekten sind Kunde und Auftraggeber identisch. Dadurch ist also der Auftraggeber während des Bazaar-Prozesses anwesend. Als Konsequenz bekommt man im Open Source-Bereich viel mehr Tools für Programmierer als fertige Software für normale Menschen. Man kann das auch als Symptom dafür interpretieren, dass niemand da ist, der den Entwickler am Zügel nimmt ...
In die gleiche Kerbe schlägt das Fehlen eines Trackers, der den Fortgang der Arbeit überprüft und die Autorität hat, lenkend einzugreifen. Sollte bei einem XP-Projekt die Arbeit nicht so fortschreiten, wie es für die aktuelle Iteration geplant war, wird ein so genanntes Stand-up-Meeting abgehalten, bei dem die Entwickler (im Stehen, um Kürze zu erzeugen) das Problem diskutieren und evtl. Aufgaben umverteilen, um im Iterationsplan nicht ins Hintertreffen zu geraten.
XP legt großen Wert auf einfaches Design. Im Bazaar-Prozess geht es häufig darum, etwas schnell zum Laufen zu bringen, um die Community aufzubauen, aber es wird oft nur wenig Wert auf YAGNI (You Aren't Gonna Need It) und OAOO (Once And Only Once) gelegt. Die Community gibt die Richtung vor, in die sich das Projekt entwickeln soll, was längerfristige Vorhersagen für Termine oder gelegentlich auch für die Richtung, in die sich die Software entwickelt, schwierig macht.
Die große Stärke von Open Source-Projekten ist die absolute Anpassung an die dezentrale Struktur im Internet. XP funktioniert am besten mit einem kleinen Team, wo alle gleichzeitig in einem Raum arbeiten können. Dagegen ist es bei Open Source-Projekten im wesentlichen egal, wer sich wann auf welchem Kontinent wie intensiv beteiligt. Diese Flexibilität sorgt auch dafür, dass Berufs- oder Ortswechsel keinen Wissensverlust für das Entwicklerteam bedeuten müssen. Wie bei allen Softwareprojekten stellt die Kommunikation jedoch immer noch den Flaschenhals dar, insbesondere, wenn das Team zu groß wird.

Interview mit Kent Beck, der seit dem C3-Projekt bei Chrysler als der Vater von XP gilt und seit langem als Zeitschriften- und Buchautor bekannt ist.

Linux Enterprise: Was ist das Geheimnis Ihrer Produktivität?
Kent Beck: Nichts zu implementieren, was nicht wirklich gebraucht wird.

LE: Was ist ihre beliebteste Computersprache und warum?
Beck: Smalltalk, da Smalltalk davon ausgeht, dass meine Zeit wichtiger als die des Computers ist.

LE: Welchen Produktivitätssprung sehen Sie in naher Zukunft auf uns zukommen?
Beck: Keinen.

LE: Was ist das größte Problem, das ein Programmierer überwinden muss, um produktiver zu werden?
Beck: Angst.

LE: Was halten Sie von generativem Programmieren?
Beck: Möglicherweise kann es die Kosten der Softwareentwicklung senken, wodurch es für Extremes Programmieren wertvoll wird.

Interview mit Alistair Cockburn, Herausgeber der Agile Software Series bei Addison-Wesley sowie Autor von drei Büchern zu den Themen Agile Softwareentwicklungsprozesse, Usergeschichten und OOP-Projekten.

Linux Enterprise: Was ist das Geheimnis Ihrer Produktivität?
Alistair Cockburn: Ohrstöpsel und Mikrotechniken. Sobald meine Ohrenstöpsel kaputt oder verloren gehen, laufe ich hinaus und kaufe ein neues Paar. Sie helfen mir sehr, meine Ruhe zu bewahren und produktiv zu sein.
Mikrotechniken sind kleine Dinge, die die tägliche Arbeit schneller machen. Wie bindet man am schnellsten seine Schuhbänder, wie kopiert man eine Spalte in der Tabellenkalkulation, wie eine Methode von einer Klasse zu einer anderen, woran merkt man, dass der Terminplan außer Kontrolle gerät? Wie legt man seine CRC-Karten am besten auf den Tisch, sodass sie einfach veränderbar sind? Ich sammle solche Mikrotechniken andauernd und bemerke, dass andere superproduktive Leute das auch tun. Kent Beck hat einen Knopf in seinen Smalltalk-Debugger gesetzt: Methode einfügen. Sobald er im Debugger eine MethodNotUnderstood-Fehlermeldung bekommt, drückt er einfach auf diesen Knopf. Das erspart vielleicht 45 Sekunden Klicken und Tippen. Der große Gewinn sind aber nicht die 45 Sekunden, sondern die Tatsache, dass sein Gedanken- und Arbeitsfluss nicht unterbrochen wurde. Zack, war die Methode da und er musste sie nur noch ausfüllen.
Wenn man sich hier und da einige solcher Unterbrechungen einspart, kann eine Mikrotechnik-bewusste Person in einer halben Stunde viel mehr leisten als jemand anders. Das macht oft gerade den Unterschied zwischen dem Erfüllen und dem Nicht-Erfüllen einer Aufgabe innerhalb einer bestimmten Zeitspanne aus. Ich habe einmal einem Projektmanager geholfen, der sich mit Tabellenkalkulationen nicht gut auskannte. Nachdem ich das Werkzeug und die Abkürzungen kannte, erstellte ich in wenigen Minuten eine brauchbare Projektvorlage, die er überhaupt nicht erstellt hätte, da er dafür einige Stunden hätte investieren müssen.

LE: Was ist ihre beliebteste Computersprache und warum?
Cockburn: Für mich sind APL, LISP, Simula und Smalltalk ganz oben, nicht nur, weil man wenig Energie aufwenden muss, um etwas zu erreichen, sonder viel wichtiger, weil man ein Repertoire an Ausdrücken aufbauen kann, mit dem das Arbeiten im Laufe der Zeit schneller und einfacher wird. Ich führe Prolog nicht in der Liste, da es zwar mit vielen Fähigkeiten beginnt, diese sich aber nicht weiter entwickeln. Ein Jahr, nachdem ich mit Prolog begonnen hatte, schrieb ich noch auf dem gleichen Ausdrucksniveau wie zu Beginn. Das passiert mit den anderen Sprachen nicht. Mit Smalltalk kenne ich mich am besten aus, deswegen ist es immer noch meine Lieblingssprache. Ich bin sicher, es gibt andere Sprachen mit ähnlichen Eigenschaften, die ich nicht gelernt habe.
Rexx ist eine andere Sprache, die für prozedurale Programme sehr schnell, einfach und ausdrucksstark ist. Die objektorientierten Versionen von Rexx waren nicht so angenehm.

LE: Welchen Produktivitätssprung sehen Sie in naher Zukunft auf uns zukommen?
Cockburn: Nichts schlägt vorgefertigte Routinen und Codegeneratoren. GUI-Designer sind die beeindruckendsten Codegeneratoren, die ich kenne. Sie erlauben es einem, Code großzügig zu verteilen, um sehr viel Spezifikation mit sehr wenig Aufwand zu erhalten. Ich habe ab und zu Programmierer Ähnliches mit Datenbanken machen sehen: Datenmodelle steuern sowohl das GUI als auch das Datenbanklayout. Leider sind diese schwer zu verallgemeinern. Tabellenkalkulationen leisten auch sehr viel Rechenarbeit bei sehr wenig Benutzeraufwand.
Deprimierend ist, dass ich keinen Produktivitätssprung voraussehe. Ich hoffe, dass noch weitere Gebiete aufgetan werden, in denen Codegeneratoren eingesetzt werden können, zum Beispiel für ferngesteuerte Funktionserzeugung oder Zugriffsmöglichkeiten, für Drag-und-Drop Datenbankoberflächen, sogar Mini-Sprachen zum Erzeugen von Testszenarien. Ob das passiert, hängt davon ab, dass Einzelpersonen die richtigen Erfindungen machen.

LE: Was ist das größte Problem, das ein Programmierer überwinden muss, um produktiver zu werden?
Cockburn: Die meisten Programmierer werden zu oft unterbrochen. Sie sollen an drei bis acht Projekte gleichzeitig arbeiten und rotieren im Kreis, wenn sie von einem Projekt zum anderen wechseln. Dann müssen sie noch den Status für jedes Projekt melden und haben keine Zeit mehr für Fortschritte.
In den produktivsten Gruppen, die ich gesehen habe, arbeiten Programmierer an einem bis 1,3 Projekten gleichzeitig. Sie sitzen da, wo sie sowohl in Ruhe arbeiten als auch nach Bedarf Fragen und Antworten stellen können. Sie arbeiten an relativ kleinen Aufgaben und machen diese vollständig fertig, bevor sie etwas anderes tun.

LE: Was halten Sie von generativem Programmieren?
Cockburn: Im Moment denke ich, dass es noch mehr Rauschen als Signal ist. Ich freue mich darauf, widerlegt zu werden :-).

LE: Wollen Sie den Lesern noch etwas mitteilen?
Cockburn: Programmieren basiert auf Fertigkeiten. Die meisten Programmierer lernen tippen und die Sprachsyntax und denken dann, für den Rest ihres Lebens ausgelernt zu haben. Gute Programmierer erweitern ständig ihre Fähigkeiten, indem sie nicht nur die neuesten Technologien erlernen, sondern auch bessere Arbeits- und Denkgewohnheiten und bessere Techniken. Lernt und verwendet zum Beispiel

• wie man ein Programm ableitet, um Randprobleme zu vermeiden (das Buch von Gries [Gries], The Science of Programming, ist gut),
• wie man effektive Unit-Tests schreibt (beginnend mit dem Herunterladen und dem Tutorial von JUnit),
• wie man verantwortungs-basiert designt, mit und ohne CRC-Karten,
• wie man ein kurzes und trotzdem effektives Benutzerszenario schreibt,
• wie man eine Mini-Sprache für Testfälle schreibt,
• wie man eine Applikation automatisiert testet,
• wie man Updates monatlich ausliefert,
• wie man einem Manager erklärt, was man getan hat und tun wird,
• und eine der Dutzend anderen Sachen, die euch effektiver machen.

Interview mit Bryan Dollery, der für die neuseeländische Computer World schreibt und Geschäftsführer der Beratungsfirma Chaos Engineers in Wellington, Neuseeland, ist.

Linux Enterprise: Was ist das Geheimnis Ihrer Produktivität?
Bryan Dollery: Schwierig (Selbstanalyse ist immer schwierig). Ich denke, man muss klug und erfahren sein. In der Regel hält man mich für einen hyperproduktiven Entwickler und ich wusste nie, wieso andere Leute nicht genauso sind.
Ich sage immer, dass nicht ich programmiere, das tun meine Finger. Meine Finger kennen die Syntax der Sprache sowie die meisten Möglichkeiten, sodass ich nur selten anhalten und über die Sprache nachdenken muss. Die meistern modernen IDEs machen das noch transparenter. Ich entwerfe Lösungsstrategien, während meine Finger sie implementieren.
Ich konzentriere mich aber nicht einmal auf ein Design. Normalerweise wähle ich einen vielversprechenden Pfad und überlasse den Rest meinen Fingern. Das geht ziemlich schnell, sodass ich schnell zurück kann, um einen anderen Weg zu wählen, wenn es eine Sackgasse gewesen sein sollte. XP hat mich gelehrt, die möglichen Wege nach ihrer Einfachheit zu bewerten, was ich mittlerweile automatisch tue.
Erstaunlicherweise löse ich Irrgärten auf die gleiche Art. Als Kind habe ich viele Labyrinthe geknackt und soweit ich mich erinnern kann, habe ich die Lösung immer gesehen und lag fast immer richtig. Angeblich habe ich einen ziemlich hohen räumlich-visuellen IQ, der hier helfen könnte, aber hohe IQ-Werte sind oft unzuverlässig (wenn IQs irgendwo zuverlässig sind).

LE: Was ist ihre beliebteste Computersprache und warum?
Dollery: Ich habe keinen Liebling, ich hasse sie alle; allerdings hasse ich Cobol mehr als die anderen ;-). Ich denke, es ist C++ wegen seiner Mächtigkeit. Generisches Programmieren mit der STL ist einfach zu cool. Stepanov und Lee sollten dafür einen Nobelpreis bekommen (Stepanov für die Idee und Lee für die Programmierung. Es ist ein absolutes Durcheinander, ich weiss nicht, wie sie es schaffen konnte, es übersteigt meinen Horizont).
Ich mag J2EE auf Grund dner breiten Anwendbarkeit. Ich kann mit den vorhandenen JavaSoft-Bibliotheken schnell sehr mächtige Applikationen erstellen. Alex Stepanov, der Autor der STL für C++, sagte, dass Java die einzige Sprache ist, von der er absolut nichts gelernt hat, da es eine rein geldorientierte Sprache ist. Was die Sprache angeht, stimme ich ihm zu, aber die Bibliotheken sind erstklassig. Was ich an Java nicht mag ist, dass es generisches Programmieren nicht unterstützt, und all die anderen Dinge, die C++ hat und Java nicht hat (wie Objektorientierung).
Ich mag Smalltalk wegen seiner Reinheit. Ich mag Basic wegen seiner Einfachheit. Ich mag Ada wegen seiner Ausdrucksstärke. Ich mag Perl, da es mich über Schönheit (beim Programmieren) belehrt hat.

LE: Welchen Produktivitätssprung sehen Sie in naher Zukunft auf uns zukommen?
Dollery: XP. Das gibt es zwar schon, aber es ist noch nicht Allgemeingut. Das wird es aber sein. Ich denke, dass wir noch nicht alles über Komplexe Adaptive Systeme wissen und darüber, was sie über soziale Interaktionen zu sagen haben.
Refaktorierungsfähige IDEs für Sprachen wie Java werden kommen. Zur Zeit sind sie ziemlich armselige Plugins, aber Borland hat gerade einige einfache Refaktorierungen (und Unit-Test Support) in JBuilder 6 aufgenommen, mit JB7 werden wir hoffentlich richtig refaktorieren können.

LE: Was ist das größte Problem, das ein Programmierer überwinden muss, um produktiver zu werden?
Dollery: Negative Einstellung und Angst, aber bei anderen Leuten. Nein wir haben keine Zeit für Unit-Tests, Wir zahlen nicht für Refaktorieren. Es ist keine produktive Arbeit. IDEs, die mich behindern. Wenn ich Zeit aufwenden muss, damit die IDE das tut, was ich will, dann bin ich nicht produktiv.

LE: Was halten Sie von generativem Programmieren?
Dollery: Abstrakte Klassen und aspektorientierte Enwicklung sind brilliante Ideen, für die es ein paar großartige Implementationen gibt. Wann immer es angemessen und durchführbar ist, benutze ich sie. In C++ benutze ich sie sehr viel, wie schon vorher erwähnt. Ich denke sie sind das Werk eines Genies.
Zur Zeit arbeite ich aber viel in Java (macht das nicht jeder?). Wegen der wirtschaftlichen Situation meiner Kunden (vor allem Finanzhäuser und Banken alter Schule) kann ich nicht einfach irgendwelche Erweiterungen von Java verwenden und nach Lust und Laune einsetzen. Das bedeutet, dass Aspekte und Templates außerhalb meines Consultinggeschäfts liegen. Ein Freund von mir zieht aber gerade eine neue Firma auf, bei der ich CTO bin, sodass in diesem Falle diese Tools mit Sicherheit im Werkzeugkasten liegen.
Allerdings werden sie meistens erst beim Refaktorieren notwendig. Wenn ich zum ersten Mal eine Logging-Funktion brauche, schreibe ich eine, beim zweiten Mal denke ich schon über die Anwendung eines Logging-Aspekts nach.
Es gab einmal eine Zeit, in der ich dachte, dass Domain Engineering das coolste Ding sei. Leider war das gerade die Zeit, als ich für mein Informatik-Diplom an der Uni gebüffelt habe. Seitdem habe ich viele Erfahrungen gemacht und meine Meinung geändert. Refaktorieren ist dafür verantwortlich.
Ich denke, dass Refaktorieren die wichtigste Entwicklung der Informatik in den letzten 30 Jahren ist. Es hat gezeigt, dass sich gutes Design entwickeln kann, anstatt spezifiziert zu werden. Meine eigenen Untersuchungen zeigen, dass gute wiederverwendbare Komponenten auf die gleiche Art und mit den gleichen Techniken entstehen können. Anscheinend können auch domänenübergreifende Komponenten so entstehen. Also geht die Domänenanalyse den gleichen Weg wie die objektorientierte Analyse, direkt ins Geschichtsbuch.
Ich denke, dass wir jetzt sowohl mental als auch softwareseitig die Werkzeuge haben, um die Evolution von Computersystemen qualitativ auf eine höhere Ebene anzuheben, als es mit vorschreibendem Design möglich war. Generatoren: Sie sind manchmal gut. Ich liebe Dinge wie JSP, wo zwei Programmiersprachen (Java und HTML) vereint werden, die dann durch das entsprechende Tool geschickt werden, um Java zu erzeugen.
Ich mag auch XSL/XSLT, um XML einzulesen und in etwas anderes zu transformieren. Ich benutze es, um meine XML-Dateien in HTML-Seiten umzuwandeln. Ich kann damit auch die gleichen Daten in PDF, ein Fax, eine eMail oder eine SMS-Nachricht umwandeln.
Es ist jedoch eine andere Art von Code-Erzeugung, aber mit Tools wie Cocoon entsteht ein unabhängig ausführbares Programm.
Dieser Artikel ist ein Auszug aus dem Buch "Produktiver Programmieren" von Armin Röhrl und Stefan Schmiedl, das demnächst im Software & Support Verlag erscheint (ISBN 3-935042-26-4).

Literatur und Links

[Agil] Agile Methodologien, www.agilealliance.org/

Grundaussage: Individuals and interactions over processes and tools.

[AuMi01] Ken Auer und Roy Miller, Extreme Programming Applied, Addision-Wesley, 2001

XP Applied kann unabhängig von anderen XP-Büchern gelesen werden, da Extremes Programmieren von Null auf erklärt wird, aufgelockert durch Fallbeispiele prominenter XP-Evangelisten (Kent Beck, Ron Jeffries).

[Beck99] Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999

Der absolute Klassiker für Programmierer und Manager, die mehr über XP wissen wollen. [Beck00] ist die deutsche Version dieses Klassikers.

[Beck00] Kent Beck, eXtreme Programmierung, Die revolutionäre Methode für Softwareentwicklung in kleinen Teams, Addison-Wesley, 2000

Die englische Version dieses Buches von Kent Beck hat die ganze XP-Welle populär gemacht.

[BeFo00] Planning Extreme Programming, Kent Beck and Martin Fowler, Addison-Wesley, 2000

Dieses Buch befasst sich mehr mit den planungsrelevanten Aspekten des Extremen Programmierens und richtet sich auch an Manager.

[Cath] www.tuxedo.org/~esr/writings/cathedral-bazaar/

The Cathedral and the Bazaar ist ein großer Klassiker von Eric Steven Raymond. Er vergleicht Open Source-Entwicklung mit Softwareentwicklung in großen Firmen.

[Cock01] Alistair Cockburn, Agile Software Development, Addison Wesley, 2001

Es gibt keinen besten Entwicklungsprozess, denn letztlich sind denkende Individuen für Erfolg oder Misserfolg eines Projekts verantwortlich. Damit werden Kommunikation und das Formen einer funktionierenden Gemeinschaft wichtiger als die Wahl des Prozesses, wobei doch die Wahl des richtigen Prozesses den Weg zum Erfolg vereinfachen kann.

[Fowl99] Martin Fowler, Refactoring, Addison-Wesley, 1999

Das erste und wohl immer noch beste Refactoring-Buch auf dem Markt. Auch wenn die Beispiele in Java geschrieben sind, sollte man dieses Buch verinnerlicht haben. Martin Fowler ist ein bekannter Experte auf dem Gebiet des Refactorings und gibt eine Unzahl an konkreten Tricks wie man die Code-Qualität verbessern kann.

[Gries] David Gries, The Science of Programming, Springer Verlag, 1981

Das Buch ist leider out of print, bietet aber eine Menge an Tipps wie man zum Beispiel typische Fehler bei Randbereichen von vornherein vermeiden kann.

[ML1] extremeprogramming@yahoogroups.com

Achtung: mehr als 100 eMails an einem Tag sind keine Ausnahme, dafür sind aber solche Größen wie Ron Jeffries, Kent Beck, etc. aktiv auf der Mailingliste.

[ML2] xp-forum@yahoogroups.de

Deutsche XP-Mailingliste. Bekannte deutsche XP-ler wie Frank Westphal und Tammo Freese sind auf der Liste.

[OSC] Kent Beck und Dave Cleal, www.xprogramming.com/ftp/Optional+scope+contracts.pdf

Jeder extreme Programmierer sollte diesen Artikel gelesen haben, bevor er einem Kunden ein Angebot macht. Im Anhang unseres Buches ist ein XP-Mustervertrag.

[TDD] Kent Beck, Test-driven development

groups.yahoo.com/group/testdrivendevelopment/files/ Eine vorläufige Version des Test-driven Development-Buches von Kent Beck. Sollte man unbedingt lesen!

[xp123] www.xp123.com/

Auf der Website von Bill Wake findet man viele praxisnahe Informationen zum Thema XP und Refaktorieren. XP ist ein bekannter XP-Guru und Buchautor.

[XPFAQ] www.jera.com/techinfo/xpfaq.html

[XPprog] www.xprogramming.com/

Zentrales Portal rund um XP von Ron Jeffries. Vielleicht die beste Website zum Thema XP.