Begrenzte Qualität – aber zackig!

Uncle Bob hat “crap code” den Kampf angesagt: “Craftsmanship over Crap” – zünftige Handwerksleistung soll für mehr Qualität in der Softwareentwicklung sorgen. Dagegen hat Nicolai Josuttis vor einigen Jahren den Gedanken geäußert, wir sollten endlich lernen, uns mit “crap code” abzufinden; er sei nicht zu vermeiden:

“So, when I say "Welcome Crappy Code", my point is not to force crappy code. My point is simply to face the reality. But, yes, you can consider my position as a view of resignation.”

Natürlich habe ich mich gegen eine solche Resignation gewendet. Nicht umsonst habe ich die Clean Code Developer Initiative mitgegründet. Ja, wir können “crappy code” aus der Welt schaffen! Wir müssen uns nur bemühen. CCD macht´s möglich.

Nun sind seitdem zwei Jahre vergangen und ich sehe die Welt ein wenig anders.

Es gibt viel Motivation in der Entwicklergemeinde, nicht länger “crap code” zu entwickeln. Die Zahl der Mitglieder in der CCD XING-Gruppe wächst ungebrochen. Das ist toll.

Ich glaube auch weiterhin daran, dass wir schlechte Qualität nicht fatalistisch hinnehmen sollten. Teams müssen besseren Code schreiben, wenn sie im Geschäft bleiben wollen. Und wir haben auch grundsätzlich die Kenntnisse, wie das geht, besseren Code zu schreiben.

Aber… ja, ich sehe da ein Aber. Der geballten Faust in der Tasche der Entwicklerschaft steht eine ökonomische und organisatorische und kognitive Macht gegenüber, die nicht zu vernachlässigen ist.

Softwarequalität (also innere Softwarequalität vor allem im Sinne von Korrektheit und Evolvierbarkeit) ist nur ein Wert unter vielen. So wie Ehrlichkeit auch nur ein Wert unter vielen ist.

Wo es aber ein Wertesystem gibt, also viele, auch noch konkurrierende Werte, da müssen Werte ausbalanciert werden. Wie in der Produktion muss das Optimum beim Ganzen eingestellt werden und nicht beim Teil.

Schon das bedeutet, dass wir nie zu optimaler innerer Qualität kommen werden. Sie wäre ein lokales Optimum, unter dem das Ganze leiden würde.

Dazu kommt, dass wir nicht einmal optimale Qualität herstellen könnten, wenn wir wollten. Wir verhalten uns in Bezug auf innere Softwarequalität nicht rational. Denn rational wäre, unsere Begrenzung durch Kosten bei ihrer Herstellung zu akzeptieren und danach abzuwägen.

Wir können nicht einmal rational entscheiden, weil neben ökonomischen und organisatorischen Gründen auch kognitive Gründe unsere Entscheidungen beschränken. Ich behaupte, dass wir nicht einmal wissen können, was die optimale Qualität wäre. Kein noch so langes Nachdenken und Diskutieren darüber würde uns zu einer eindeutigen Lösung bringen. Der Grund dafür liegt in der Volatilität der Anforderungen. In einer kleinen Serie zu den Gesetzen der Softwareentwicklung hatte ich dazu schon einmal etwas gesagt.

Es geht also nicht. Verabschieden wir uns von der Vorstellung hohe oder gar optimale innere Qualität herzustellen. Wir bewegen uns nicht im Bereich der Rationalität, sondern müssen unter Bedingungen Beschränkter Rationalität (Bounded Rationality) arbeiten.

Unser Ziel kann eingebunden in ein Netz von Werten nur eine genügend gute innere Softwarequalität sein. Wir müssen uns mit “good enough” bescheiden. Auf allen Ebenen: bei der Architektur, bei der Modellierung, bei der Implementierung. Immer kriegen wir nur “good enough” hin. Das sehe ich als Annäherung an Nicolais Standpunkt.

Also: Mehr Qualität, ja! Aber den Anspruch an die Qualität begrenzen.

Das bedeutet zum Beispiel, wir können uns das ganze Gerede über Eleganz sparen. Eleganz ist etwas für Leute mit viel Zeit. Eleganz ist Verfeinerung. Und damit gewinnt man keine Schlacht.

Ebenso können wir uns längliche Diskussionen über alle Prinzipien von Clean Code Developer sparen. Sollte die Methode auf dieser Klasse oder jener definiert sein, damit das SRP eingehalten wird? Solche Fragen müssen ohne Zweifel erörtert werden – doch am besten in einer Timebox. Wenn darüber nach 10 Minuten keine Einigung mit Argumenten erzielt werden kann, dann sollte der Code so bleiben, wie er ist. Die Zukunft wird zeigen, wer in der Diskussion Recht hatte.

Die Prinzipien und Praktiken von Clean Code Developer behalten ihren Wert – aber nun sehe ich noch eine Herausforderung, die darüber hinausgeht:

Wie kommen wir möglichst schnell zu einer “good enough” Softwarequalität? Eine Liste mit Werten und Prinzipien auf Kärtchen ist nicht genug. Gedruckt sind die nämlich geduldig. Und auch die Mahnung, man solle sich täglich um sie bemühen, ist geduldig. Im Tagesgeschäft ist das schwer. Und das nächste Refactoring ist immer weit. Und TDD ist auch nicht einfach.

Nein, ich glaube, wir müssen anders vorgehen, um schnell zu “good enough” zu kommen. Wir müssen das Schreiben der Software so verändern, dass quasi automatisch und ohne lange Diskussion “good enough” rauskommt. Alles, was nicht sofort beim Schreiben passiert, passiert nämlich tendenziell gar nicht.

Das hat TDD im Grunde schon begriffen – nur ist die Refactoring-Phase sehr unspezifisch.

Also: Wie können wir zügig begrenzte Qualität in unserer begrenzten Rationalität herstellen? Wie setzen wir uns sinnvoll Grenzen in der Entwicklung, um schlicht nicht mehr soviel falsch machen zu können?

Spendieren Sie mir doch einen Kaffee, wenn Ihnen dieser Artikel gefallen hat…