Gedanken zu Gedanken zum TDD

Nach einer TDD-Demonstration bei der NUG Franken hat sich eine lebhafte Diskussion um einen kritischen Blog-Artikel von René Drescher-Hackel entsponnen. Das ist ein schöner Effekt der Demonstration und gut fürs Thema.

Zu einigen Punkten finde ich das Diskussionsergebnis allerdings noch unbefriedigend.

Darf´s ein bisschen mehr sein als Visual Studio? Aber sicher doch!

René hat sich über den scheinbaren Zwang von ReSharper mokiert. Ich stehe da auf einem anderen Standpunkt und finde nichts dabei, Unternehmen den Kauf von Tools zu empfehlen, auch wenn das Investitionen von 1.000, 5.000 oder gar 10.000 EUR bedeuten sollte. Unsere Branche ist so privilegiert und deshalb verwöhnt, was die Werkzeugkosten angeht im Vergleich zu Tischlern, Klempnern, Kirmesschaustellern, Ärzten usw., dass ich über solche Beträge nicht zweimal nachdenke.

Einen Entwickler ein Jahr lang jeden Arbeitstag auch nur 15 Minuten länger an einer Aufgabe sitzen zu lassen als nötig, ist so teuer, dass ein Tool wie ReSharper oder TestDriven.Net usw. sich schnell bezahlt macht. (Beispielrechnung: 60 EUR kostet der Entwickler/Stunde, er arbeitet 200 Tage im Jahr, dann entstehen 15 EUR*200=3.000 EUR Verlust pro Jahr dadurch, dass ihm ein Tool oder auch nur Kenntnise fehlen, die seine Arbeit um nur ca. 3% beschleunigen.)

René sagt:

Viele Unternehmen, die Software entwickeln sind Microsoft-Partner. Was dies wirtschaftlich für diese Unternehmen bedeutet, brauche ich hier nicht zu erklären. Du kannst aber nicht in einem Unternehmen auflaufen und TDD propagieren und gleichzeitig sagen, "wenn wir gescheit arbeiten wollen, dann brauchen wir...". Die Grunderwartung ist: was können wir mit den gegebenen Möglichkeiten tun?

Das kann ich nachvollziehen. Das ist eine “Grunderwartung” vieler Programmierbuden. Aber nur weil die Erwartung so ist, ist sie nicht “richtig” oder realistisch. Kinder haben auch viele Erwartungen, was die Weihnachtsgeschenke angeht – leider sind viele davon auch nicht realistisch.

Softwareentwicklung ist eben keine Sache mehr, die man mit Notepad und einem Kommandozeilencompiler bewältigen könnte. Das mag 1984 noch gegangen sein – aber heute nicht mehr. Der Arzt hat heute nicht mehr nur ein Messer oder einen Haken, um einen grauen Star zu stechen. Sein Gerät ist deutlich umfangreicher und teurer. Damit musste sich die Ärztezunft auch abfinden. Wir als Patienten freuen uns darüber und wollen es nicht mehr anders.

Wer meint, mit Visual Studio allein professionelle Softwareentwicklung betreiben zu können, der ist schon lange auf dem Holzweg. Sich auf Microsoft und Visual Studio zu verlassen, ist bequem. Es macht die Toolkosten planbar, die vor allem in einer MSDN Subscription bestehen oder in einem Update alle 2-3 Jahre. Doch seit wann lassen sich Fachleute von Controllern vorschreiben, was ihre Werkzeuge sein und kosten sollten?

Für mich ist also das, was René zu ReSharper gesagt hat viel weitgreifender. ReSharper war nur ein Stein des Anstoßes. Der Punkt ist jedoch allgemeiner. Es besteht eine merkwürdige Vorstellung davon, wie Produktivität in der Softwareentwicklung entsteht. Aber ich schweife ab… ;-)

Apokalyptischer Reiter Resignation

René sagt:

Dass der Softwareentwickler die Tests für sich im Kleinen macht, ist eher Wunschdenken bzw. der Idealfall. In den Firmen/Projekten, wo ich bislang tätig war, war dafür kein Platz. Und glaube mir Thomas, irgendwann gewöhnst du es dir ab, mit deinem Projektleiter/Vorgesetzen darüber zu diskutieren - so ist das ebend.

Für das, was richtig ist, ist kein Platz. Und wenn das so ist, dann nimmt man es hin.

Verständlich mag das sein. Aber traurig ist es, nein, tragisch und vor allem kontraproduktiv. Niemand hat etwas davon – außer demjenigen, der sich in die Resignation zurückzieht. Und der auch nur kurzzeitig, denn Resignation führt auf Dauer zu Schlimmerem.

Ich halte Resignation für einen Apokalyptischen Reiter für Softwareprojekte. Wo Resignation aufkeimt, erblühen und sich verbreiten kann, da scheitern Projekte. Resignation ist das Gegenteil von Motivation.

Was kann man dagegen tun?

Masterfrage: Braucht TDD (oder eine andere Veränderung) “Platz”? Ich würde sagen, nein. Oft braucht eine Veränderung keinen “Platz” im Sinne von “Darüber müssen wir alle einig sein” oder “Dafür muss extra Zeit veranschlagt werden”. Viele Veränderungen können nämlich einfach so vom Einzelnen vorgenommen werden. Man tut schlicht etwas anderes als bisher.

Ob ich nach einer Besprechung sofort an die Tastatur hechte und den Code-Colt ziehe oder neuerdings erstmal mit einem Block auf dem Tisch nachdenke… darüber muss ich mit niemandem reden.

Ob ich mit dem Code-Colt sofort aufs Ziel schieße oder erstmal einen Spike mache oder einen Test schreibe… darüber muss ich mit niemandem reden.

Ob ich die Pfadfinderregel befolge, meine Klassen nach SRP, SoC, LSP usw. anders schneide als früher… darüber muss ich mit niemandem reden.

Wer in seiner persönlichen Begeisterung gleich andere zu Proselyten machen will, der darf sich nicht wundern, wenn er auf Gegenwehr stößt. Resignation ist dann jedoch nicht die einzig mögliche Reaktion. Man kann zunächst auch einfach den Missionsdrang runterfahren und soviel wie möglich ohne Übereinstimmung mit anderen tun. Einfach unter dem Radar der Projektleitung fliegen.

Und wenn dann einer fragt, “Solltest du nicht lieber mal programmieren, statt wieder über deinem Block zu hocken?”, dann kann man ruhig auch mal die Vertrauensfrage stellen: “Vertrauen Sie mir nicht, wenn ich erst nachdenke und dann programmiere? Ist meine Leistung schlechter geworden?” (Und wenn darauf unwahrscheinlicherweise die Antwort “Ja!” kommt, dann kann man auch mal um die Messdaten bitten, die das belegen. )

Darüber, was es bedeutet, wenn man immer wieder gegen Wände läuft mit Vorschlägen für Veränderungen, will ich mich hier nicht weiter auslassen. Jeder muss für sich selbst entscheiden, ob das ein lohnenswertes Arbeitsumfeld ist, immer wieder in seiner Motivation, Vorgehen und Ergebnisse zu verbessern, frustriert zu werden. Ob längerfristige oder gar zunehmende Resignation gesundheitszuträglich sind, sollte man dann mal einen Arzt oder Apotheker fragen ;-)

Besser wird es schon, wenn man bei sich beginnt

René sagt:

Ich bin überzeugt davon, dass wenn du testgetrieben entwickeln willst, es nur wirklich sinnvoll ist, wenn im Team alle mitziehen - andernfalls sehe ich es als Kampf gegen Windmühlen. Die gleiche Situation hast mit den Fragen zum CCD.

Warum ist testgetriebene Entwicklung nur sinnvoll, wenn alle im Team mitziehen? Natürlich wäre das besser für das Produkt, weil dann mehr Code so entwickelt würde. Aber für mich als Entwickler ist das nicht wichtig. Ich kann meine Vorteile aus TDD schon ziehen, wenn ich allein damit anfange. Und der Kunde hat auch schon etwas davon, wenn nur ich so arbeite. Denn dann ist zumindest mein Code von höherer Qualität.

Darauf zu warten, dass eine Veränderung erst allgemein akzeptiert ist, um sie selbst vorzunehmen, ist frustrierend und unnötig. Für manche ist es nicht anders möglich, z.B. die Einführung einer verbindlichen Versionskontrolle für alle oder eine Continuous Integration. TDD gehört jedoch nicht in diese Gruppe. Wer etwas anderes behauptet betreibt Prokrastination durch “Schuldverschiebung”: “Die anderen sind Schuld, dass ich nicht nach TDD arbeiten kann.”

TDD kostet kein Geld, da kein Tool gekauft werden muss. NUnit ist gratis und reicht aus. TDD braucht keinen Konsens, da ich an den Codeteilen, die ich bearbeitet, nach TDD vorgehen kann.

Wenn andere sich darüber lustig machen, dann ist das deren Problem.

Entwickler sind keine Arbeitsbienen

René sagt:

Test sollten immer vom Architekten der vorgegeben werden. Der Entwickler (die Arbeitsbine also ;-) ) setzt die Software anhand des Tests um. So ist letztlich sichergestellt, dass die Software so funktioniert, wie der Architekt die Anforderung auch umgesetzt hat. Das ist meines Erachtens auch der tiefere Sinn der TDD.

Oha, das ist starker Tobak. Und das mir als Nichtraucher… ;-) Architekten sollen Tests vorgeben? Entwickler sind Arbeitsbienen?

Architekten sollen zwar die Nützlichkeit von Software sicherstellen worin ihre Korrektheit eingeschlossen ist. Doch dass Architekten deshalb Tests vorgeben sollten… nein, das halte ich für eine irrige Vorstellung.

Architekten sollen Entwickler und/oder Kunde helfen, angemessene Testszenarien zu formulieren. Sie sollen dem Kunden klar machen, wie wichtig es ist, dass er klare Vorstellungen von Korrektheit entwickelt und dokumentiert. Am besten in Form maschinenlesbarer Dokumente, die Testläufe treiben. Tools wie Fitness machen das möglich.

Und Architekten sollen den Entwickler im Rahmen eines expliziten Entwicklungsprozesses immer wieder über sein Verständnis der Anforderungen reflektieren lassen, aus dem heraus der dann weitere Testfälle formulieren kann. Dazu gehört auch, dass der Architekt TDD im Team einführt, falls noch nicht etabliert.

Doch Tests definiert der Architekt selbst nicht. Allerdings kann er vertreten, dass ausdrückliche semantische Kontrakte für bestimmte Funktionseinheiten formuliert werden, insbesondere wenn deren Entwicklung outsourcet ist.

Der “tiefere Sinn” von TDD ist eben nicht, dass Tests von irgendwoher kommen und der Entwickler nur krampfhaft versucht, die auf grün zu bringen. Nein, dem Entwickler dienen TDD-Tests über eine Korrektheitsprüfung hinaus zu…

• Ermittlung von Schwachstellen im Verständnis von Anforderungen und der Planung von Code
• angemessener Strukturierung nach SLA und SRP
• hoher Testabdeckung
• Dokumentation

TDD ist ein zentrales und unverzichtbares Entwicklungs- und Denkwerkzeug.

Und jetzt noch zur “Arbeitsbiene”. Das hat René nicht ganz ernst gemeint, aber ein wenig schon. Sonst hätte er nicht die Grenze zwischen Architekt und Entwickler so gezogen.

Dass solche Titulierung nicht zum Selbstbild von uns Softwareentwicklern gehört, ist klar. Ein solches Fremdbild mag es jedoch hier und da geben. “Ach, die klopfen doch nur Code ein.” Vielleicht ist es in manchen Projekten auch so. Und für Anfänger sind die Vorgaben sicherlich auch enger als für erfahrene Entwickler.

Am Ende könnte das Bild der “Arbeitsbiene”, d.h. eines Entwicklers, der in engen Vorgaben nur noch “runtercodiert”, nicht weiter von der Notwendigkeit entfernt sein. Entwickler dürfen keine “Arbeitsbienen” sein. Denn sobald sie das werden, bricht Software unter der Komplexitätslast zusammen.

Software ist so komplex, dass sie nicht einer vordenken kann. Weder im Hinblick auf die Umsetzung von Anforderungen, noch in Bezug auf Lösungsdetails in Algorithmen und Technologieeinsatz.

Softwareentwicklung braucht kooperative autonome Entwickler. Keine “Bienenköniginnen” oder gar “Drohnen” und keine “Arbeitsbienen”. Softwareentwickler sollten vielmehr innerhalb einem recht weiten architektonischen Rahmens viel Freiheit besitzen. Sie müssen fähig sein, lokale Probleme kreativ zu lösen. Und sie müssen fähig sein zu kommunizieren, was sie allein nicht lösen können, um es gemeinsam auf höherer Ebene zu lösen.