Softwareentwickler machen keinen Dreck. Softwareentwickler tun auch nichts Überflüssiges. So scheint mir jedenfalls der Anspruch.
Die Realität sieht am Ende natürlich ganz anders aus: der Dreck ist im Code überall, es stinkt mächtig (code smells). Und vom Überflüssigen ganz zu schweigen. Wenn premature optimization laut Donald Knuth „the root of all evil“ ist, dann findet sich Überflüssiges allerorten im Code.
Natürlicher Müll
Woher kommt dieser Anspruch aber? Andere Berufe haben kein Problem, Dreck zu machen und Überflüssiges in Form von (temporären) Hilfskonstruktionen herzustellen. Das tun sie ganz bewusst. Es ist geradezu sprichwörtlich: „Wo gehobelt wird, da fallen Späne.“ Genau! Das ist auch nicht schlimm, wenn man am Ende der Arbeit die Späne zusammenfegt und entsorgt.
Überall entsteht Abfall in irgendeiner Form während Dinge hergestellt wird. Der ist eigentlich überflüssig, lässt sich jedoch trotz fleißigen Bemühens nicht komplett vermeiden. Späne, Bauschutt, Nahrungsmittelabfälle, Abwasser… Die Transformationseffizienz ist eben nicht 100%. Input kann nicht perfekt in Output überführt werden.
Doch wo ist solch bewusst in Kauf genommener Dreck, Abfall, Müll bei der Softwareentwicklung? Ich sehe ihn nicht. Es entsteht zwar Dreck, nur unbewusst. Er wird nicht als solcher wahrgenommen. Das halte ich für ein Problem. Nur TDD hat dafür ein Auge: im dritten Schritt nach Red und Green soll mit Refactoring aufgeräumt werden. Leider wird selbst das aber nur selten getan.
Softwareentwickler durchlaufen keine Lehre, in der ein fester Bestandteil das Aufräumen ist. Tischlerlehrlinge, Kochlehrlinge, Schlosserlehrlinge hingegen lernen alle die (Wieder)Herstellung von Ordnung am Ende von Arbeitsphasen. Dreck wird zusammengekehrt, Werkzeug wird in Schubladen und Regale weggeräumt. In einer Küche ist das sogar extrem. Da wird nicht bis zum Tagesende gewartet, sondern ständig gewischt und gespült. Während die eine Hand mit dem Kochlöffel rührt, putzt die andere schon entstandene Spritzer weg. Das ist ein simples Gebot der Hygiene, wenn schon nicht der Produktivität.
Ich finde das ganz natürlich. Sogar würde ich sagen, Abfall bewusst und kontrolliert entstehen zu lassen, ist eine Sache der Effizienz. Denn wenn ich in jeder Sekunde sauber sein muss, wenn ich nie Dreck erzeugen darf… dann werde ich langsam, weil ich ja ständig nicht nur meine eigentliche Aufgabe verfolgen muss, sondern auch auf permanente Sauberkeit zu achten habe.
Sauberkeit und Ordnung sind wichtig – aber nicht in jeder Sekunde. Phasen, in denen Späne fallen, und Phasen, in denen die Späne zusammengefegt werden, dürfen, ja sollten sich sogar abwechseln. Solche Natürlichkeit ist allerdings aus meiner Sicht weder im Bewusstsein der meisten Entwickler noch in dem ihrer Vorgesetzten gewachsen.
Hilfreiche Konstruktionen
Dasselbe gilt für Hilfskonstruktionen. Die werden auch als überflüssig angesehen. Warum nur? Weil sie von vornherein als Abfall erscheinen und daher vermieden werden müssen? Dabei arbeitet der Rest der Welt damit ständig: Häuser werden eingerüstet, Schiffe auch, Autos kommen auf Hebebühnen, Schiffe auch, es gibt Kräne, es gibt Schuttrohe am Bau usw. usf.
Diese Hilfskonstruktionen sind dazu da, die Arbeit am Werkstück zu erleichtern. Und am Ende werden sie abgebaut. Das Haus steht wieder frei, das Auto auf der Straße, das Schiff liegt im Wasser. Nichts mehr zu sehen von den so nützlichen Hilfskonstruktionen. Man war sich nicht zu fein, zusätzlichen Aufwand für deren Auf- und Abbau zu treiben. Denn dadurch konnte die eigentliche Arbeit viel effizienter gestaltet werden. Unterm Strich also ein Gewinn.
Nur die Softwareentwicklung kennt das nicht. Dort gibt es keine Hilfskonstruktionen, die bewusst temporär aufgebaut und nach der eigentlichen Arbeit wieder abgebaut werden. Selbst bei TDD, wo ja sogar Abfallbeseitigung „eingebaut“ ist, sind Hilfskonstruktionen unbekannt. Alle Tests sollen erhalten bleiben. Aber warum? Gibt es denn keine Unterschiede bei Tests? Ich sehe sehr wohl Tests, die eigentlich nur temporär nützlich sind. Die nenne ich Gerüsttests – denn ich baue sie nach getaner Arbeit wieder ab. Der Gewinn: der Code wird übersichtlicher, die Angriffsfläche für Regressionen wird verringert.
Dabei gibt es das Konzept des Prototyps in der Softwareentwicklung. Nur wird der regelmäßig entgegen der Begriffsdefinition nicht weggeschmissen, sondern zum Produkt umgebaut.
XP kennt spike solutions. Auch das Code, der am Ende weggeworfen wird. Nur wer „spiket“ denn bewusst? Das scheint mir selten trotz immer wieder hoher Unsicherheiten im Verständnis von Anforderungen oder beim Einsatz von Technologien.
Seit Jahren gibt es auch das Konzept Kata, also Übungsaufgabe. Entwickler treffen sich gelegentlich, um gemeinsam an Katas etwas zu lernen. Doch das sind Einzelne, vielleicht höchstens 5% aller Entwickler. Denn eines ist ja klar: der Code zu einer Übungsaufgabe ist am Ende Abfall. Der kann weg, ist nicht im Tagesgeschäft einsetzbar. Also denken sich 95% der Entwickler, dass es wohl nicht lohne, ihn überhaupt zu schreiben. Der ist überflüssig.
Ab auf die Werkbank!
Vielleicht ist ja ein Grund für die „Abfallaversion“, dass die Softwareentwicklung auch keinen Unterschied machen zwischen dem Ort, wo ein Teil bearbeitet wird, und dem, wo das Teil in einem Ganzen eingebaut ist. Softwareentwicklung findet immer am endgültigen Marmorblock statt. Alles wird aus einem Stück herausgemeißelt. Kein Wunder, dass der Softwaremonolith allgegenwärtig ist.
Das mag ja gut gehen, wenn man Michelangelo heißt und wahrhaft meisterlich mit Marmor umgehen kann. Doch normale Entwickler sollten sich doch eigentlich nicht an so einer Aufgabe probieren. Viel einfacher ist es, ein Ganzes aus Teilen zusammenzusetzen, die man einzeln auf Werkbänken bearbeitet. Doch das geschieht nicht. Code, der zum Einsatz beim Kunden kommt, ist immer eingebaut im Ganzen. Man kann vielleicht auf ihn von außen mit Tests zugreifen, es gibt also Revisionsklappen. Doch das ist ein Zugeständnis an das Paradigma „aus einem Stück hauen“.
Bei TDD as if you meant it wird dieses Paradigma aufgebrochen – doch wer kennt diesen TDD-Ansatz?
***
Abfall, Hilfskonstruktionen, Werkbänke… das alles sind keine Themen in der Softwareentwicklung. Mir scheint das ein Problem zu sein. Der schlechte Stand der inneren Codequalität ist für mich umso weniger ein Wunder. Wenn wir uns die Freiheit nicht nehmen, etwas „Verschwendung“ zuzulassen, um dafür auf der anderen Seite fokussierter und effizienter zu arbeiten, dann machen wir noch keinen guten Job als Software Craftsmen oder Software Engineers.