2015 May 14
Im Laufe der vergangenen Woche habe ich die Podcasts zur Diskussion „Is TDD dead?“ von Martin Fowler, Kent Beck und David Heinemeier Hansson gehört. Die Diskussion hat ihren Ursprung in der Keynote der „Railsconf“, in der David Heineneier Hansson (stark abgekürzt) die These aufstellt, dass TDD heute neben den positiven Aspekten auch viele Probleme verursacht und nicht mehr im ursprünglichen Sinn der Idee hilfreich ist. Die Episoden des Podcasts sind aus einer Reihe von Blogeinträgen und Diskussionen unter den drei Teilnehmern entstanden, die dann per google Hangout eine offene Diskussion über die Ursprünge und den aktuellen Stand von Testdriven Development führten.
Die Podcasts sind auf jeden Fall sehr spannend und ich kann nur empfehlen, sich die Diskussion anzuhören. Mein persönlicher Eindruck im Rückblick ist allerdings, dass sich die Diskussion eigentlich gar nicht um Testdriven Development selber dreht, sondern dass das Thema lediglich der Auslöser für eine grundlegendere Debatte um den Sinn und die Grenzen von Methoden und Prozessen allgemein ist.
Die Diskussion beginnt mit einigen Beispielen für übermäßige Nutzung von TDD an einigen Stellen, an denen der Einsatz mehr Aufwand als Nutzen bringt. Genau da liegt dann meiner Meinung nach der Denkfehler – nur weil ein Einsatzort für eine Methode unsinnig oder nicht sinnvoll ist, ist ja nicht die Methode falsch. Jeder Prozess ist für eine bestimmte Menge von Problemfeldern entworfen worden und kann dort hilfreich sein. Es gibt aber genug benachbarte oder entfernte Problemfelder, die von dem Prozess wenig bis gar nicht profitieren können. Es gibt in der Softwareentwicklung sicher genug Ecken, in denen TDD mehr Aufwand verursacht als die Ergebnisse rechtfertigen. TDD ist dadurch aber nicht falsch oder schlecht, man muss TDD nur – wie jedes andere Werkzeug auch – kennen und nutzen lernen. Wer nur einen Hammer hat, sieht überall Nägel…
Bei jeder neuen Methode oder jedem neuen Werkzeug dass man kennenlernt, durchläuft man üblicherweise einen Einschwingvorgang, den man mit einer Impulsantwort eines Regelkreises vergleichen kann. Hat man die Methode für hilfreich befunden gibt es zu Beginn einen Überschwinger, bei dem man die Methode zunächst auf alle denkbaren Problemfelder anwendet. Dabei sind dann zwangsläufig auch die Felder, bei denen die Methode mehr Kosten als Nutzen verursacht. Dies gehört aber zum Lernprozess, denn hinterher weiß ich genauer, wo mir die Methode helfen kann – und wo nicht.
Ich hatte vor dem Hören der Podcasts eine andere Erwartungshaltung und hatte mehr mit den konkreten Problemen von TDD gerechnet, im Rückblick finde ich die Diskussion aber eher noch spannender als erwartet. Eine Diskussion von drei so erfahrenen Softwareentwicklern über den Sinn, Unsinn und den Nutzen und die Grenzen von Methoden und Prozessen allgemein, das ist schon lehrreich.