Software-Putzmänner und die nächste IT-Revolution

Anfang August war ich auf der Agile 2008 in Toronto. Diese Konferenz scheint sich inzwischen als die Konferenz für professionelle IT im allgemeinen zu etablieren und die OOPSLA abzulösen.

Interessant war der Bankett-Vortrag von "Uncle Bob", wie Robert C. Martin in der Community dort genannt wird. Sein Credo gipfelte in dem Ausspruch "Craftmanship over Crap" und war im Grunde wieder einmal die übliche Klage aller professionell arbeitenden IT-ler, dass wir uns bei der Softwareentwicklung zu wenig Zeit für Qualität nehmen. Wir haben zu wenig Zeit, die Dinge richtig zu machen, und zu wenig gute Leute und produzieren eigentlich nur noch "Crap" (laut Leo: Mist, Unsinn oder sogar noch etwas Vulgäreres).

Martin verwendete dabei die Analogie der Ärzte, die sich früher geweigert hatten, sich zwischen zwei Patienten bzw. zwischen einer Autopsie und einem Patienten die Hände zu waschen, und den Vorschlag des Händewaschens als absurd bezeichneten. Diese übertrug er auf die Softwareentwicklung, wo wir uns nicht die Zeit nehmen, zwischen zwei Änderungen an Code aufzuräumen. Implementieren erzeugt schlechten Code, solange man sich nicht die Zeit zum Aufräumen nimmt.

Am Tag darauf hatte ich einen Vortrag über den Umgang mit großen Systemlandschaften und dass es dort schlichtweg keine Zeit für guten Code gibt. Eine Lösung aus meinen Erfahrungen besteht darin, das Einbauen von Features (also das Erfüllen dringender fachlicher Anforderungen) von Aufräumarbeiten organisatorisch zu trennen. Es gibt also separate Refactoring-Teams, die unabhängig von den Feature-Teams sind. Man könnte sie als "Software-Putzfrauen/-männer" betrachten.

Eine berechtigte Frage dazu aus dem Publikum war, ob ich damit nicht genau dem von Bob Martin angeprangertem Problem Vorschub leiste, dass wir Aufräumen nicht mehr als notwendiges "Händewaschen" und Teil jeder Codierung betrachten.

Dies führte bei mir zu einer interessanten Gedankenkette:
Zunächst einmal habe ich die Erfahrung gemacht, dass man der Softwareentwicklung schlichtweg nicht mehr die Zeit gibt, aufzuräumen. Wer dafür Zeit verplant, der verliert unter Umständen Ausschreibungen und Marktmacht. Insofern, richtig, fördere ich dies noch, wenn ich zum Aufräumen Putzmänner und -frauen einstelle. Das kann man auch als Kapitulation betrachten.

Man kann es aber auch anders sehen. Vielleicht sollten wir einfach das Undenkbare denken und schlichtweg akzeptieren, dass Code immer in einem schlechten Zustand ist und dass dies in der heutigen Zeit als gegeben betrachtet werden muss. Anstatt gegen schlechten Code anzukämpfen, sollten wir lieber geeignet mit schlechtem Code umgehen.

Und da machte es Klick bei mir. "Akzeptieren statt dagegen anzukämpfen" hatte ich in jüngster Vergangenheit doch schon mehrfach gehört. Und jedesmal führte das zu einer Revolution:

• Bei Agilität haben wir unser Wertesystem daran angepasst, dass es eine Tatsache ist, dass sich Anforderungen ändern, und aufgehört dagegen anzukämpfen.
• Bei SOA haben wir unser Wertesystem daran angepasst, dass es eine Tatsache ist, dass große Systeme heterogen sind, und aufgehört, Harmonisierung als Lösung zu betrachten

Und jetzt ist es also an der Zeit, dass wir unser Wertesystem daran anpassen, dass Code immer in einem schlechten Zustand ist. Anstatt dies zu bekämpfen und als Fehler anzusehen, sollten wir mit dieser Tatsache sinnvoll umgehen. Fragt sich natürlich wie. Aber das ist eine andere Frage.