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.

Time to go back to basics!

Nicht umsonst gehören die “Boy Scout Rule” und “Root Cause Analysis” zu den Basics der Softwareentwicklung. Häufig stolpert man selbst im eigenen Code über ungewöhnlich Variablennamen, Schleifenkonstrukte, “Managerklassen” oder Workarounds. Es genügen häufig kleine Änderungen und der Code wird übersichtlicher und erspart einige Kopfschmerzen beim Debuggen. Insbesondere Workarounds sind gefährlich. Sie erscheinen einem das Leben schnell zu erleichtern und das Problem aus der Welt zu schaffen. Besonders wenn wieder einmal der Chef im Nacken sitzt. Doch die hier gewonnene Zeit wird mit hohen Zinsen erkauft. Wer hat nicht schon einmal ein komplettes Modul neu schreiben müssen? Wird unter die Oberfläche des Problems gesehen und das Übel an der Wurzel gepackt, stellt man zudem oft fest, dass sich ein Problem nicht nur sauberer, sondern viel einfacher lösen läßt als gedacht. Die genannten Prinzipien lassen auch in vielen anderen Bereichen gut nutzen oder wie gut ist euer Schreibtisch aufgeräumt? Oder wiederspricht eurer Meinung nach gar alles dem “Keep It Simple, Stupid”-Prinzip und Prokratinationsstapel sind der beste Weg Ordnung zu halten?