XP, TDD und Vibe Coding: Teilübersetzung eines Programmatic-Engineer-Interviews mit Kent Beck

• Zusammenfassung einiger Passagen aus dem Programnatic Engineer-Interview mit Kent Beck, dem Vater von XP und TDD, die mich besonders beeindruckt haben
• Wer Kent Beck mag, dem sei das vollständige Video empfohlen

---

F. Was ist der Kern von XP?

Es geht darum, diese vier Aktivitäten auszuführen.

1. Herausfinden, was getan werden muss
2. Herausfinden, welche Struktur es uns ermöglicht, 1 umzusetzen
3. Mit 2 dann 1 implementieren
4. Prüfen, ob 3 wie erwartet funktioniert

Das ist alles. Und man unterteilt die Zeit in sehr kleine Einheiten, sodass man in jeder Zeiteinheit alle vier Aktivitäten ein wenig, aber eben alle, ausführt.

F. Ist Pair Programming in XP dann also nicht verpflichtend?

Als wir zum ersten Mal ein XP-Team betrieben, haben wir alle drei Wochen ausgeliefert, und natürlich gab es Bugs.

Wir haben die Muster der Bugs analysiert, die nach dem Release entdeckt wurden, und dabei festgestellt, dass sie ausnahmslos aus Code stammten, der allein entwickelt worden war. Andersherum gesagt: In Code, der im Pair entwickelt worden war, gab es keine in Produktion gemeldeten Defekte.

F. Also nicht verpflichtend, sondern eher eine starke Empfehlung?

Auch das nicht. Man soll experimentieren. Man kann gern so entwickeln wie bisher. Aber eben wachsam.

Will man die Vorteile von kontinuierlichem Design, kontinuierlicher Verifikation, kontinuierlicher Implementierung oder kontinuierlicher Interaktion mit dem Kunden? Wenn es aber mit der bisherigen Arbeitsweise einfach nicht klappt, dann muss man den Ansatz ändern.

Wenn jemand zu mir kommt und sagt: "Kent, ich mache kein TDD.", dann antworte ich: "Na und?"

Wenn du mit der Defektdichte in deinem aktuellen Code und mit dem Maß an Feedback zu deinen Designentscheidungen zufrieden bist, ist das in Ordnung. Wenn nicht, dann probiere eben Pair Programming oder TDD aus.

F. Wenn wir schon dabei sind: Warum hast du TDD erfunden?

Ich bin ein Mensch, der sich viele Sorgen macht und leicht verunsichert ist, und Programmieren war für mich eine ständige Quelle von Angst. Was habe ich vergessen? Was habe ich kaputtgemacht?

Wenn ich aber mit TDD entwickle, verschwindet diese Unsicherheit. Mir fällt kein weiterer Testfall mehr ein, der fehlschlagen könnte? Dann kann ich sicher sein, dass mein Programm funktioniert. Kommt auch nur ein kleines Gefühl der Unsicherheit auf? Dann schreibe ich einfach den nächsten Testfall.

Natürlich hat TDD auch viele technische Vorteile: geringere Defektdichte, schnelleres Feedback zu Designentscheidungen, evolutionäres Weiterentwickeln des Implementierungsdesigns und mehr. Aber für mich ist am wichtigsten, dass ich von der Angst vor dem Programmieren befreit wurde, dass sich die emotionale Erfahrung des Programmierens vollständig verändert hat. Deshalb habe ich TDD erfunden.

F. Was hältst du von der Kritik von John Ousterhout, dass TDD keinen Raum für gutes Design lasse?

(Hinweis des Übersetzers: John Ousterhout ist der Autor des bekannten Buches Philisophy of Software Design und hat vor einigen Monaten im Programmatic Engineer-Podcast ebenfalls eine kritische Sicht auf TDD geäußert.)

Er missversteht dabei etwas. Das ist einfach nur das Ergebnis einer Entscheidung. Wenn man TDD nur als Wiederholung von Red-Green behandelt, dann gibt es dort natürlich keinen Raum für Design.

Als TDD-Praktiker bewege ich mich bei der Arbeit ständig zwischen verschiedenen Abstraktionsebenen. Zum Beispiel:

• Im Moment bin ich im Red-Zustand. Wie muss ich implementieren, damit der nächste Testfall erfolgreich wird (Green)?
• Irgendetwas ist schwierig. Warum ist es schwierig?
• Wie muss ich das Design ändern, damit die Implementierung für Green einfacher wird?
• Wann sollte ich diese Idee einführen? Jetzt oder später?
• Wenn ich sie jetzt einführe, in welchem Umfang? Nur so viel, wie ich sofort tun kann, oder in einem größeren Chunk?

Das heißt: Bevor ich einen Test schreibe, habe ich immer einen Moment des Designs.

Bevor ich implementiere, treffe ich eine Entscheidung über das Interface, erzeuge einen Red-Test, und weil ich den Red-Zustand nicht mag, bringe ich ihn so schnell wie möglich auf Green. Sobald es Green ist, verschwindet die Unsicherheit kurz, und ich habe wieder Raum zum Nachdenken. "Hm, es läuft zwar durch, aber für andere Fälle wird das nicht reichen. Ich sollte die Implementierung verallgemeinern."

Red? Dann mache ich es Green. Green? Dann halte ich kurz inne und denke nach. Das ist mein TDD-Zyklus.

F. Manchmal erscheint mir die Implementierung so offensichtlich, dass ich zuerst implementiere und danach Red-Green-Tests mache. Was hältst du davon?

Dann gehst du vermutlich von der Annahme aus, dass "diese Implementierungsweise richtig ist". Und je richtiger diese Annahme ist, desto geringer ist natürlich der Vorteil eines testgetriebenen Vorgehens.

Ich denke aber immer so: "Ich werde weiter lernen und Erfahrungen sammeln, und jetzt gerade ist der Moment, in dem ich am wenigsten weiß."

Ich gehe also davon aus, dass ich weiter lernen werde und dass sich die Situation verändern wird. Je mehr ich noch lernen muss und je stärker sich die Lage verändern wird, desto mehr möchte ich Entscheidungen möglichst weit nach hinten verschieben. Das ist ein allgemeines Prinzip. Beim Dating genauso wie beim Kochen.

Je mehr man vorhersagen kann, desto größere Sprünge kann man machen. Aber der Moment, den ich beim Programmieren am meisten liebe, ist der, wenn ich denke, ich hätte alles verstanden und würde einfach durchziehen, und dann plötzlich merke: Es gibt eine viel bessere Art zu implementieren. Solche Momente möchte ich so oft wie möglich erleben. Deshalb mache ich TDD.

Wenn du ein klares Bild im Kopf hast und sicher weißt, welcher Input welchen Output erzeugt, dann implementiere einfach. Aber je mehr Fehler du machst, je mehr du lernst und je unvorhersehbarer sich die Welt verändert, desto vorteilhafter ist es, sich jetzt noch nicht festzulegen und die Entscheidung auf später zu verschieben.

F. Entwickelst du beim Coden mit AI immer noch wie früher mit TDD?

Das lässt sich nicht einfach beantworten.

Ich nutze Tests als Kommunikationsmittel mit der AI, vor allem um der AI mitzuteilen, was sie falsch gemacht hat. Dieses Ding versucht ständig, meine Tests zu löschen oder zu verändern, und dann schimpfe ich es aus. Meine Tests sind korrekt, also soll es seine Arbeit ordentlich machen.

AI trifft langfristig oft schlechte Entscheidungen. Sie ist wirklich schlecht darin, Kopplung zu senken und Kohäsion zu erhöhen. Wenn man ihr sehr klar sagt, was zu tun ist, kann sie es manchmal schaffen, aber im Allgemeinen muss man sagen, dass sie schlecht im Design ist.

Deshalb bereite ich sehr viele Tests vor. Ich nutze sie als Mittel, um zu erkennen, ob die AI gerade irgendetwas kaputtmacht.

(Hinweis des Übersetzers: Wie Kent Beck TDD beim Vibe Coding einsetzt, wird in diesem Beitrag beschrieben.)

F. Es wäre doch angenehmer, wenn Agent-Regeln wie "Ändere niemals Tests; wenn Tests nicht durchlaufen, ändere nur den Implementierungscode, bis sie durchlaufen" weiter verbreitet wären. Es wirkt auch so, als würden wir gerade Dinge wiederentdecken, die in den 2000ern wichtig waren. Was denkst du darüber?

Wir müssen weiter experimentieren. Wir müssen alles ausprobieren, was möglich ist. Denn im Moment wissen wir nicht, was wirklich am besten ist.

Der Horizont dafür, was "billig" und was "teuer" ist, hat sich komplett verschoben. Viele Dinge, die früher als teuer oder schwierig galten und die man deshalb nicht gemacht hat, sind heute absurd billig geworden.

Wenn Autos plötzlich von einem Tag auf den anderen kostenlos wären, was würde dann wohl passieren? Natürlich würde sich etwas ändern. Aber wie sähen die Folgen zweiter und dritter Ordnung aus? Das kann niemand vorhersagen. Deshalb bleibt uns im Moment nichts anderes übrig, als vieles auszuprobieren.

F. Du hast gesagt, dass dir Programmieren nach mehr als 50 Jahren heute am meisten Spaß macht. Was meinst du damit?

Es ist so leicht wie noch nie geworden, meine großen Ideen umzusetzen. Zu beobachten, ob die AI diese Idee implementieren kann, und zu steuern, wie sie das tut, ist extrem suchterzeugend. Man weiß nie genau, wann es gut funktioniert, und wenn es dann wie durch Magie klappt, ist das berauschend. In dieser Hinsicht ist es wie ein Spielautomat. Bevor ich spazieren gehe oder Mittag essen gehe, will ich diesen Kerl nicht einfach untätig lassen, und ich werde ständig von dem Wunsch erfasst, vorher wenigstens noch einen Prompt zu schreiben.

Vor zwei Jahren habe ich getwittert: "Ich hatte Hemmungen, ChatGPT auszuprobieren, und heute habe ich diese Hemmungen überwunden. Jetzt verstehe ich, warum ich sie hatte. 90 % meiner Fähigkeiten sind jetzt auf $0 gefallen. Und der Hebel für die übrigen 10 % hat sich um das 1000-Fache erhöht. Ich muss mich neu justieren."

> I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
>
> The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
>
> -- Kent Beck 🌻 (@KentBeck) April 18, 2023

(Hinweis des Übersetzers: Als dieser Tweet damals Aufmerksamkeit bekam, schrieb Kent anschließend noch einen etwas längeren Beitrag.)

Damals sagte er noch, dass er erst erkunde, was diese 90 % und 10 % eigentlich seien. Inzwischen kann er darauf einigermaßen antworten. Die Fähigkeit, eine kühne Vision zu haben, Meilensteine auf dem Weg dorthin zu setzen und beim Voranschreiten das Design immer wieder anzupassen und dabei die Komplexität unter Kontrolle zu halten. Das ist eine sehr viel wichtigere Fähigkeit als Wissen über die Syntax einer bestimmten Sprache (zum Beispiel: Wo setzt man in Rust &, * oder [ ein?).