Als Gast(autor) ziemt es sich ja eigentlich nicht gegenüber dem Gastgeber in irgendeiner Form mäkelig zu sein. Zumal es sich bei dem Gastgeber um ein von mir über die Maßen geschätzten und respektierten Software-Architekten und -Entwickler handelt. Doch sein zuletzt hier veröffentlicher Aufruf “Time to go back to the basics” erregte doch in mir Widerspruch, den ich auf diesem Wege loswerden möchte.
In seinem Aufruf kritisierte mein Gastgeber das Verwenden von Workarounds bei der Software-Entwicklung. D. h., das Verwenden von kleinen Quelltext-Fragmenten, mit denen Probleme nur auf die Schnelle und nur vordergründig gelöst werden sollen. Stattdessen soll man wie ein guter Pfadfinder bei jeder Gelegenheit die Workarounds wegräumen und Ordnung im Quelltext schaffen — selbst dann, wenn man die Unordnung nicht verursacht hat.
Doch hier regt sich bei mir Widerspruch, so daß ich meinem Gastgeber im Sinne Feyerabends (1997) entgegenrufen möchte: No, anything goes! Denn, um es mit den Worten Paul Feyerabends zu formulieren, kein Programmcode ist “so alt oder so absurd, daß er nicht unser Wissen verbessern könnte. (Feyerabend, 1997, S. 55). Denn woher weiß man den, daß der Workaround, den man da gerade beseitigen will, das Problem ist? Kann es denn nicht auch so sein, daß die Idee, die hinter dem Workaround steckt, die eigentlich bessere ist, als die hinter dem vermeintlich ordentlichen Quelltext? Kann man das vor allem dann wissen, wenn der Quelltext nicht von einem selber ist?
Denn dies setzt voraus, daß man die Absichten und die Ideen des Urhebers richtig erkannt und verstanden hat, was nicht immer der Fall sein muß. Und Aufräumen würde dann die Unordnung, die man dort beseitigen will, erst schaffen. Hier versagt daher die Metapher der Pfadfinderregel. Im Wald mag jeder leicht erkennen, daß ein Faß mit Giftmüll dort nicht hingehört. Aber ein vermeintlicher Workaround, ist am Ende gar keiner, da er nämlich nur das Ergebnis unkonventionellem und unorthodoxem Denken ist, zu dem man vielleicht selbst aufgrund der ganzen Pfadfinderregeln nicht mehr fähig ist. Denn dies sollte nicht vergessen werden, wenn man nach Ordnung und Clean Code ruft. Software-Entwicklung ist ein kreativer Akt, bei der es auch — wenn nicht sogar primär — um die Entwicklung von Ideen und nicht nur um die sture Produktion von Quelltext.
Wenn ich in diesem Sinne rufe: “Anything goes!”, heißt dies aber auch, daß ich meinem Gastgeber in einem Punkt zustimme. Denn mit die Software-Entwicklung soll dadurch nicht der Beliebigkeit anheim gestellt werden. Hierfür bedarf es schon einige grundlegender Regeln und Prinzipien, um die Software-Entwicklung zu einem erfolgreichen Abschluß zu bringen. Doch die Regeln und Prinzipen sind abhängig vom Kontext, d. h. von der Anwendungsdomäne und dem Zweck der Software, der Entwicklungsumgebung, den eingesetzte Techniken usw. Und die Regeln und Prinzipien, die in der einen Situation zum Erfolg führten, können in der nächsten versagen. Ein beliebiges und stures anwenden der immer gleichen Regeln und Prinzipien kann genauso schädlich sein, wie eine regel- und prinzipienlose Beliebigkeit.
Literatur
Feyerabend, P. (1997). Wider den Methodenzwang (6. Aufl.). Frankfurt am Main: Suhrkamp.


