Follow my new blog

Freitag, 2. April 2010

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?

image 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.

image 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.

image 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.

4 Kommentare:

Unknown hat gesagt…

Habe den Artikel auch vor einigen Tagen gelesen und war sehr erfreut über die Kommentare, die dadurch entstanden sind.

Ich finde es sehr gut, dass Du nochmals heraushebst, dass ein Entwickler TDD auch ohne Zustimmung des Teams machen kann (Man hört nämlich immer wieder, dass das alle Teammitglieder machen müssen, da es sonst nicht funktioniert, was mir persönlich nie wirklich eingeleuchtet hat)

Insgesamt ein schöner Artikel, welchem ich mit gutem Gewissen zustimmen kann.

Anonym hat gesagt…

Ich glaube es würde dem Test Driven Development gut tun, wenn es gelegentlich weniger rigeros propagiert werden würde.
Willst Du Menschen zu etwas bewegen musst Du Sie da abholen, wo sie sich befinden. Einem Entwickler zu sagen: 'So wie Du gegenwärtig arbeitest ist das ganz falsch, richtig ist nur TDD', wird ihn erstmal in Abwehrstellung gehen lassen.
Meiner Meinung nach heisst das Credo auch 'Test everything that could possibly break' und nicht 'Test all the f%&$ing time'.
Wenn ich CRUD Funktionalität mit einem extensiv getesteten ORM schreibe, dann sehe ich keinen Vorteil im Schreiben eines Tests vor dem Anlegen der Methoden.
Da tut man sich auch mit der Vermittlung der Notwendigkeit schwer.
Wenn ich aber einen komplizierten Algorithmus kodiere, den ich auf der Suche nach dem Optimum permanent verändere, bringen mir Unit Tests sowohl in der gedanklichen Strukturierung als auch in der Prüfung des Codes etwas. Dann kommt auch der Riesenvorteil zur Geltung, daß ich nach einem Refactoring Gewissheit über die Funktionalität bekomme.
In diesem Fall ist es auch für technisch weniger begabte Pojektleiter viel besser nachzuvollziehen ;-)

Was mir aber viel mehr zu denken gibt, ist diese LMA Einstellung gegenüber der Softwareentwicklung.
Die Situationen, die Rene beschreibt kenne ich und derjenige der so handelt wie Du es vorschlägst ist ganz schnell als unsozial gebrandmarkt.
Pervers aber wahr.
Meine Erfahrung ist die, daß je grösser die Entwicklergruppe, desto eher heisst es 'Scheiss auf gute Ratschläge, let's do Colt Coding - the fastest wins'
Wartbarkeit, Eleganz, Konsitenz - ach komm hör auf, in 6 Monaten bin ich auf einer anderen Baustelle.
Ich gehe davon aus, mindestens 80 % dieser Menschen haben sich doch einmal aus Neigung der Softwareentwicklung zugewand. Wie kann diese Zuneigung so verlorengehen. Ich rätsele schon lange über diesen Mechanismus, richtig erklären kann ich mir das immer nocht nicht.

Grüsse

Joachim

Ralf Westphal - One Man Think Tank hat gesagt…

@Joachim: TDD kann leider nicht nicht rigoros vermittelt werden. Man kann es nicht ein bisschen tun. Entweder tut man es und kann man es oder nicht.

Aber man kann natürlich steuern, wo/wann man es tut. Vielleicht fängt man an, es bei Übungsprojekten (Stichwort Kata) mal auszuprobieren, bevor man auf eine Missionsreise damit in der Projektgruppe startet.

Ich behaupte nicht, dass man aus dem Stand einfach mit TDD im Projekt loslegen soll. Ich behaupte aber: 1. TDD ist state of the art und unverzichtbar. 2. Jeder kann es lernen. 3. Jeder sollte Gelegenheiten suchen, TDD in seine Projekte "einzuschleichen".

Wir haben alle lange ohne TDD gelebt - mich eingeschlossen ;-) Aber jetzt ist die Branche schlauer. Das zu leugnen bzw. dem sich zu widersetzen, ist unprofessionell.

Veränderung ist immer schwer. Aber das macht sie nicht falsch, sondern nur lästig.

Einen CRUD DBAdapter kann und soll man nach TDD entwickeln wie einen Zuschnittoptimierungsalgorithmus. (Wobei es beim Algorithmus weniger Unterstützung durch TDD gibt, da TDD nicht zu optimierten Algorithmen führt, sondern eher nur zu naheliegenden.)

Dass beim CRUD DBAdapter womöglich weniger zu testen ist als beim Algorithmus ist doch ok. Vielleicht muss ich da nur 4 Tests schreiben, die die Interaktion mit dem ORM prüfen. Spricht das gegen TDD? Nein, dafür. Denn daran zeigt sich, dass TDD keinen speziellen Anspruch hat, viele Tests zu schreiben. Es sollen nur soviele wie nötig sein.

Softwareentwickler aus Neigung - ja, das ist wohl häufiger so. Und dann eine LMAA Haltung. Wie passt das zusammen? Ich finde, das ist recht einfach: Die Zeit der Prägung (Ausbildung oder Autodidaktentum) prägt keine professionelle Haltung, sondern eine der Regierung des Lustprinzips und der schnellen Erfolge. Es zählt was funktioniert. Es zählt, was schnell gemacht wurde. Es zählt nicht, wie du zur Funktion gekommen bist.

Das fördert Halbwissen und bringt die Metakompetenz "Lernen können" nicht weiter. Und so sind viele Softwareentwickler einmal auf einen Stand gekommen über den leichten Aufstieg - und haben dabei nicht gelernt, dass sie nicht auf dem Gipfel stehen, sondern nur im Basislager. Und ihr Arbeistumfeld hilft ihnen nicht, diese Fehlwahrnehmung zu korrigieren.

Das Ausbildungssystem ist ein großes Problem. Und ein Missverständnis bei denen, die Softwareentwickler einstellen bzw. "hüten". Es werden die falschen Werte propagiert. Oder zumindest nur einseitige Werte.

-Ralf

Rene Drescher-Hackel hat gesagt…

Hallo Ralf,

vielen Dank für deine ausführliche Stellungnahme zu diesem Thema. Man könnte Bücher darüber schreiben - oder auch nicht, zu dem was ist und was besser sein sollte oder lieber nicht ist bzw. nicht sein sollte. Wie dem auch sei.

In dem kleinen Team, dem ich derzeit angehöre, haben wir ganz klar gesagt: egal wie "bescheiden" der Einstieg ins TDD fällt, wir werden es vorantreiben - mit allen uns zur Verfügung stehenden Mitteln.

Gruß
Rene