extreme programming oder "alles was man wissen muss, lernt man schon im kindergarten"

(von mariann unterluggauer)

Zwei Gründe führt Brian Foote von der amerikanschen Firma Refactory Incorporated dafür an, warum Programmierer dazu neigen Code lieber neu zu schreiben, als alten zu lesen: Sie vertrauen nur den Dingen, die ihnen bekannt sind. Das heißt ihrem eigenen Code. Dieses Verhalten wird noch dadurch verstärkt, dass das entschlüsseln von fremden Codezeilen nur selten leicht zu bewerkstelligen ist. Das hantieren an fremden Programmzeilen kann leicht zu einem Hasardspiel werden, denn nur selten sind die Auswirkungen von Veränderungen abschätzbar, wenn man das Programm nicht als Ganzes überblickt.

Brian Foote: "Programmiersprachen sind nicht immer gut darin, die Geschichte ihrer eigenen Entstehung nachzuerzählen. Viele haben sich bereits daran versucht Techniken zu entwickeln, die dabei helfen sollen, Code richtig zu schreiben; wie man 'erzählender' programmiert, damit weniger in externen Bildern oder Dokumentation erläutert werden muss."

Selbsterklärende Codes sind rar. Je länger ein Projekt andauert, desto unverständlicher werden manche Codes, da im Verlauf einer Entwicklung zuviele neue Anforderungen berücksichtigt wurden. Programmieren bedeutet nach wie vor Chaos und Evolution. Nur selten sind die Rahmenbedingungen von vornherein klar. Mit der Entstehung von objektorientierten Programmiersprachen wie Smalltalk oder Java versuchte man den Alltag von Programmierern durch Dinge wie Flexibilität und Wiederverwendbarkeit von Programmteilen zu erleichtern. Bereits vor ein paar Jahren setzten sich Anhänger dieser Programmierschule wie Ward Cunningham, Kent Beck und Ron Jeffries zusammen, um das Problem prinzipieller anzugehen. Bei Extreme Programming geht es unter anderem auch darum, so Brian Foote, der vorherrschenden rigiden, bürokratischen Methodologie von Softwareentwicklung, die in einer ISO Norm zusammengefasst wird, etwas menschlicheres entgegenzusetzen. Mit Werten wie Einfachheit, Kommunikation, Feedback und Courage sollten "Extreme Programmer" von Befehlsempfängern zu aktiven Spielern in einem Team mutieren. Aber dazu müssen Programmierer zuerst ganz prinzipielle Dinge lernen: wie zum Beispiel Kommunikation.

Brian Foote: "Es gibt interessante Erkenntnisse darüber, wie Programmierer untereinander ihre Kommunikation verbessern könnten. Das ist eines der Dinge, die man beim Pair-Programming sehen kann. In der Welt des "Extreme Programming" gibt es die Bemühung, das Programmierer nicht nur prinzipiell mehr miteinander reden, sonder auch das sie Informationen darüber austauschen, welche Auswirkung ein Code-Fragement hat."

"Pair-Programming", das gemeinsame arbeiten am Code von zwei Programmierern, ist ein zentraler Punkt von "Extreme Programming". Programmierern fehlen die interessierten Zuhörer, meint Brian Foote. Unter Kollegen wird selten offen über Probleme geredet, viel seltener als über das ehrenwerte Ziel eines sauberen und lesbaren Codes. Über die allgegenwärtigen "quick and dirty hacks", mit denen Sonderwünsche der Kunden schnell befriedigt werden, schweigt man in der Branche lieber. Das Programmieren im Team soll dieser Tendenz entgegensteuern.

Brian Foote: "Bei "Pair-Programming" hat man plötzlich Zuseher. Jemand liest deinen Code. Damit wird etwas ausgelöst, dass man auch in der Open Source Welt beobachten kann: Sonnenlicht hat diese Auswirkung, Infektionen zum abheilen zu bringen. Und zu wissen, dass jemand deinen Schrank öffnen wird, bringt dich dazu, aufzuräumen und Dinge sauber zu halten. Und dieser Prozess bringt auch beim Programmierer eine Alarmlampe zum leuchten und führt dazu, dass Codes sorgfältiger kultiviert werden."

Das erste und bislang größte Softwareprojekt, das nach den Regeln von "Extreme Programming" absolviert wurde, wurde von Kent Beck für die Firma Daimler Chrysler geleitet. Kent gilt als Schöpfer der Bezeichnung "Extreme Programming". "Extrem" steht dabei für die Tendenz, alles was sich bewährt hat, in übersteigerter Form anzuwenden.

"Ich nahm alles, was ich über das Programmieren wusste, und drehte die Knöpfe auf 10: Zu testen ist eine gute Sache, also testeten wir jeden Tag; das reden mit den Kunden ist eine gute Idee, also setzten wir sie in den selben Raum wie die Programmierer; Design ist nicht schlecht, also verwendeten wir jeden Tag Zeit dafür. Das war die ursprüngliche Prämisse, und daher kommt die Bedeutung des Wortes "extrem" bei Extreme Programming."
(Auszug aus einem Interview mit Kent Beck)

Daimler Crysler hatte begonnen, ein eigenes Lohnverrechnungs-System zu entwickeln. Das Projekt drohte zu scheitern, und Kent Beck sollte retten, was noch zu retten war. Er schaffte mit seiner Methode des Programmierens fast innerhalb des vorgebenen Zeitrahmens. Das Prinzip des "Pair Programmings" wurde dabei nicht nur beim Schreiben des Programmcodes eingesetzt, sonder auch beim Entwurf des Systems und den ständigen Tests.

Es gibt auch Kritiker an diesem Ansatz. Andy Krall vom Institut für Computersprachen an der TU- Wien, kann der Methode, zwei Programmierer vor einen Rechner zu setzen wenig abgewinnen. Was jedoch Andy Krall als "Verlassen auf andere" bezeichnet, nennen Extreme Programmer "Vertrauen" und "Teamarbeit". Nach dem Motto: Zwei Augen sehen mehr als eines, soll das gemeinsame Sitzen vor einem Rechner nicht nur das mühsame suchen nach Tippfehlern verhindern, sondern auch helfen, den Fokus nicht zu verlieren. Damit rechnet sich diese Methode auch finanziell: die Zeit des Debuggings wird verringert und das Software läuft stabiler. Die Methode folge zu sehr ökonomischen Gesichtspunkten als menschlichen, lautet auch prompt ein andere Vorwurf an die Anhänger von Extreme Programming. Manche Programmierer, aber auch Manager und Kunden, eignen sich nicht zur Teamarbeit und wären mit so einem Ansatz hoffnungslos überfordert. Vor zwei Jahren veröffentlichten Laurie Williams und Robert Kessler eine Studie, deren Titel lautet: "Alles, was man für das Programmieren im Team braucht, lernt man schon im Kindergarten".

Share everything
Jeder ist gleichberechtigt und alle gemeinsam produzieren ein Artefakt.

Play fair
"Pair-Programming" heißt, dass ein Programmierer die Tastatur kontrolliert, während der andere versucht, den Überblick zu bewahren. Beide sind aktiv, denn nur jemanden beim Tippen auf die Finger zu schauen, ist ungefähr so spannend wie dem Gras in der Wüste beim sterben zuzusehen, meint auch Kent Beck, der Namensgeber von "Extreme Programming"

Don't hit your Partner,
aber sieh zu, dass er nicht abschweift, dass weniger Zeit beim lesen von e-mails, Webpages oder beim Blick aus dem Fenster verloren geht.

Put things back where they belong
Selbstzweifel sollen verworfen werden, denn sie bremsen nur den Arbeitsverlauf und bringen keinem etwas. Man behebe sie am besten indem man von anderen lernt und damit beginnt, seine eigenen Ideen zu artikulieren.

Clean up your mess.
Tippfehler und andere Flüchtigkeitsfehler werden von einem Partner schneller wahrgenommen und damit auch schneller bereinigt. Auch verursacht der Blick über die Schulter bei konstanter Teamarbeit weniger Probleme, als die Entdeckung eines kleinen Fehlers bei einer beiläufigen Inspektion.

Don't take things too seriously.
Egoistisches Verhalten - kann Programmierer davor abhalten, über andere Ideen ernsthaft nachzudenken, und sollte deshalb vermieden werden.

Say you're sorry when you hurt somebody while moving furniture.
Die Veränderung der Arbeitsplatzsituation wird bei "Pair-Programming" essentiell. Cubicles und getrennte Büros für Programmierer und Manager gibt es bei Extreme Programming nicht. Denn sie verhindern die notwendige Kommunikation und sind oft genug nur Hinweise auf versteckte Machtspiele.

Wash your hands of skepticism before you start.
Viele Programmierer stehen dem Arbeiten im Team sehr skeptisch gegenüber. Sehr oft hat das aber mehr mit der Entstehung des Teams zu tun: die besten Erfolge wurden erziehlt, wenn die Teams unter den Programmierern selbst gebildet wurden. Kritiker meinen, dass eben diese Zusammenstellung der kritische Punkt bei "Extreme Programming" sei.

Flush!
Von Zeit zu Zeit müssen Programmierer auch ausserhalb des Teams an Code arbeiten. Nach den Regeln von "Extreme Programming" nichts schlimmes, vorausgesetzt die Zeilen, die Programmierer alleine geschrieben haben, werden später im Team besprochen, getestet und - wenn nötig - auch wieder verworfen. Alternativ dazu schlagen die Verfasser der Studie, Laurie Williams und Robert Kessler, vor, allein geschriebenen Code gleich wegzuwerfen und im Team neu zu schreiben. Schliesslich würden sich die hartnäckigsten Fehler im Programmcode in den Zeilen finden, die von einem Programmierer allein erstellt wurden.

Warm cookies and cold milk are good for you.
"Pair Programming" ist ermüdend, weil zu zweit meist konzentrierter an der Lösung eines Problems gearbeitet wird. Regelmäßige Pausen sollte daher eingehalten werden. In einem Interview erzählte Kent Beck, dass es ihm beim Einsatz von "Extreme Programming" auch darum geht, Programmierern wieder eine 40 Stunden Woche zu ermöglichen.

Live a balanced life - learn some and think some and draw and paint and sing and dance and play and work every day some.
Um Programmierern ein soziales und privates Leben zu ermöglichen, wird die Funktionalität der zu erstellenden Software von vornherein auf das Wesentliche beschränkt.. Programmierer müssen im Gegenzug lernen, von Dingen, die nicht notwendig sind und Features, nach denen niemand gefragt hat, die Finger zu lassen. Egal wie einfach das Hinzufügen einer neuen Funktionalität auch erscheinen mag. Eine Disziplin, zu der nur wenige Programmierer fähig sind: zu gross ist oft die Versuchung, schnell mal eben eine neue Funktion zu implementieren.

Manchmal hat der Zwang, unbedingt noch dieses oder jenes in einen Code zu zwängen, aber auch mit dem ausgeprägten Ego von Programmierern zu tun, meint Brain Foote. Unter Programmierern gilt das ständige Nachschieben von Features nicht nur als Nachweis für die Flexibilität des eigenen Codes, sondern auch als Hinweis auf die Qualitäten seines Schöpfers.

Prinzipiell stimmen alle, Kritiker wie Befürworter von Extreme Programming darin überein, dass bei der Entwicklung von Software nie jede Möglichkeit ihres späteren Einsatzes vorhergesehen werden kann. Sowohl die Ausgeglichenheit des Programmierers ,als auch die Ausgewogenheit des Systems leiden unter dieser scheinnbar unumstößlichen Prämisse. Extrem Programming versucht diesem Trend dadurch entgegenzuwirken, dass sich das ganze Team - vom Kunden über das Projektmanagement bis hin zum Programmierer - auf die "Politik der kleinen Schritte" einigt. Die Zeit, die ein Projekt benötigt, soll dadurch verkürzt werden, indem sich jeder an gemeinsam beschlossene Vorgaben hält und nicht im nachhinein beginnt, Funktionalitäten hineinzureklamieren. Alle Erweiterungen, die nicht von essenzieller Wichtigkeit für die erste Release sind, sollen auf spätere Updates verschoben werden.

Doch XP versucht noch weiter, die verbreitete evolutionäre Programmierung zu verändern:
Wähle den einfachsten Weg, um Dinge zu tun.

Zu oft wird der einfachste Weg verworfen, weil das Resultat der geforderten "Schönheit des Codes" widerspricht oder in den Augen des Programmierers zu "unflexibel" ist. Dass die einfachste Lösung aber auch nach langer Zeit noch einfach zu verstehen ist, wird dabei oft vergessen.

"Du wirst es nicht brauchen".
Alles, was nicht jetzt gerade benötigt wird, sollte auch nicht implementiert werden. Einerseits um Code möglichst verständlich zu halten, andererseits auch um Programmteile, deren Zweck später nur mehr mühsam rekonstruiert werden kann, zu vermeiden. Und nicht zuletzt muss guter Code - so XP - sowieso ständig überarbeitet werden.

Damit das gesamte Bündel an Methoden umgesetzt werden kann wie das Programmieren in Paaren, das ständige Testen und die Kommunikation zwischen allen Beteiligten, müssen noch einige Parameter in der Branche verändert werden. Die Diskussion über Extreme Programming hat erst begonnen. Kunden und Projektmananger müssen lernen, ihre Wünsche zu artikulieren. Programmierer werden zu oft als das letzte Glied in der Kette betrachtet und mit Vorwürfen wie: "Warum geht das nicht?" oder: "Warum ist das noch nicht fertig?" konfrontiert, obwohl das eigentliche Problem an ganz anderer Stelle zu finden wäre. Das Entwickeln von flexiblen, wiederverwertbaren Systemen fordert Investitionen von allen Beteiligten.

Brian Foote: "Die Befriedigung fühlt man dann, wenn man fähig ist den Menschen Dinge zur Verfügung zu stellen, die deren Arbeitsbedingungen verbessern. Man macht die Menschen glücklich, indem man die Maschinen dazu bringt etwas zu tun, was sie zuvor noch nie getan hat. Irgendwie fühlt man sich dabei schon wie der Weihnachtsmann. Aber dieses Gefühl ist befriedigend und ist mit ein Grund dafür, warum ich ein Programmiere sein wollte."

matrix