Software als Handwerk?

Ein Welle der Empörung überschwemmte Dan North in der letzten Woche. Sein Post: ‘Programmieren ist kein Handwerk’ (http://dannorth.net/2011/01/11/programming-is-not-a-craft/) entzündete eine breite Diskussion. Im Normalfall würden ein paar hundert Menschen seinen Blog lesen, dieses Mal seien es 20000 innerhalb weniger Tage gewesen. Nach 4 Tagen hatte der Post 150 Kommentare. Worum geht es?

Dan North schreibt Programmieren sei kein Handwerk (craft) sondern ein Beruf (trade). Wenn meine schwachen Englischkenntnisse und meine kurzen Recherchen mich nicht trügen, dann zielt der Begriff ‘craft’ in die Richtung Handwerk, Kunsthandwerk, Ehre des Handwerks (Arbeitsethos), während ‘trade’ mit Geschäft, Gewerbe, Handel verwandt ist. Der Gegensatz, auf den Dan North zielt wird vielleicht am deutlichsten in folgender Passage: “… I want an expert programmer enabling my business. What I don’t want, however, is a prima donna plumber who insists on talking about the elegance …” Dan North zielt auf einen latent in der agilen Softwareentwicklung verhandelten Gegensatz. Ist qualitativ gute Software essentiell für die agile Softwareentwicklung? Ist sie Selbstzweck? Ist sie Mittel zum Zweck?

Der Anlass für Dan North Bemerkung ist das Manifesto for Software Craftmanship (http://manifesto.softwarecraftsmanship.org/). Das Manifest lehnt seine Form an das Agile Manifest an. Es versucht die Qualität der Software stärker ins Zentrum der Bemühung von Programmierern zu rücken. Dan North hat es nicht unterzeichnet, wenn man seinen Post liest, weiss man auch warum.

Ich möchte nicht zu der Debatte Stellung beziehen, sondern zwei Gedanken äußern, die mir schon seit längeren durch den Kopf gehen. Der erste Gedanke hat unmittelbar mit dem Begriff Handwerk zu tun. (Handwerk in dem emphatischen Sinne, den craft meint.) Meine eigene Erfahrung ist, dass sich TDD nicht wie die Anwendung einer beliebigen Praktik erlernen lässt. TDD (also Test-First-Programming) erfordert eine längere Phase der Übung und diese Phase ist anstrengend. Erst nach einem disziplinierten mehrmonatigen Sich-selbst-immer-wieder-dazu-zwingen stellt sich so etwas wie eine Vertrautheit ein. Wenn die Umerziehungsphase zu kurz ist, fällt man wieder in die alten Praktiken zurück. Als Bild habe ich einen Berg vor Augen. Wenn man erst einmal den Gipfel überschritten hat, ist der Weg zurück ebenso verbaut. Nachdem ich mich daran gewöhnt hatte praktisch jeden, nicht völlig trivialen Code mit Tests einzubetten, war es ein komisches Gefühl in bestimmten Kontexten darauf zu verzichten. Ähnlich stelle ich mir auch den Lernprozess in einem klassischen Handwerk vor. Der Lehrling begleitet den Gesellen ein paar Jahre lang, schaut ab, macht mit, handelt selbst, wird korrigiert und irgendwann ist es ihm ‘in Fleisch und Blut’ übergegangen. Die Theorie dazu, das Warum, spielt dabei kaum eine Rolle. Das ‘Immer und immer wieder’ steht im Mittelpunkt. Deshalb mag ich Handwerk/Craft als Begriff, es drückt diese wichtige Erfaghrung aus.

Aber – ohne dieses Aber wäre das hier ja doch ein Plädoyer für eine Seite – aber, ein Gedanke, den ich bei Kent Beck gelesen habe, hat mich nicht mehr in Ruhe gelassen, ohne dass ich ihn schon umsetzen, anwenden ohne nur richtig einordnen könnte. Leider habe ich ‘auf die Schnelle’ keine Referenz gefunden. In der gemeinten Passage beschreibt Kent Beck, wie schwer es ihm falle Quick-and-Dirty zu programmieren. Aber, so geht der Gedanke weiter, es sei eben Verschwendung, wenn wir jedes Codestück mit einer Superqualität auslieferten. Es ginge vielmehr darum, schnell etwas auszuliefern, um mit diesem Experiment zu sehen, was geht und was nicht, was angenommen wird und was nicht. Und anhand der Ergebnisse aus diesem Experiment kann man sagen, ob überhaupt weiter programmiert werden müsse und in welche Richtung das gehen solle. Die Zweige, die sich dann als entwicklungsfähig herausstellten, seien mit aller gebotenen handwerklichen Qualität zu verfertigen, aber eben auch nur genau die. Ich finde diesen Gedanken sehr gut. Er ist aber schwer zu verwirklichen. Ich spüre einen Unbill sobald ich etwas ‘nur mal so dahinrotze’. Ein schlechtes Gewissen macht sich breit. Die Gefühle aus dem TDD-Umerziehungslager rumoren im Bauch. Softwarequalität als Selbstzweck lässt sich viel einfacher zum Maßstab machen. (Wohlgemerkt: zum Maßstab, was noch nicht verwirklichen heisst.) Wenn ich das ganze Kontinuum von Quick-and-Dirty bis vollständig-getestet-wohldesigned-stabil ausreizen wollte, müsste ich den Kontext stärker in Rechnung stellen, die Feedbackschleifen müssten kürzer, effektiver und bewußter werden. Es ginge darum Experiment zu formulieren und duchzuführen.

Mit meinen zwei Gedanken finde ich mich auf beiden Seiten des Gegensatzes wieder. Das Handwerk ist mir wichtig, weil es die Essenz des Programmierenlernens bedeutet. Die Rückkoppelung des Kunden ist mir wichtig, weil sie allein der Qualität als Maß dienen kann.