Seite 2: Berührungspunkte

Inhaltsverzeichnis

Berührungspunkte zu anderen Initiativen

heise Developer: Damit seid ihr allerdings nicht allein. Wie grenzt ihr euch von anderen Bewegungen ab?

Westphal: Natürlich sind wir mit Clean Code Developer nicht die einzigen, die etwas zu innerer Qualität sagen. Teile von eXtreme Programming (XP) widmen sich auch der inneren Qualität (zum Beispiel Refactoring, Pair Programming). Doch XP ist zunächst mal ein Vorgehensmodell; es nimmt die Entwickler in Bezug auf innere Qualität nicht genügend an die Hand.

Dann gibt es in den USA die Software-Craftsmanship-Bewegung. An ihr ist auch Robert C. Martin beteiligt. Da gibt es sicher mehr Berührungspunkte mit Clean Code Developer – doch die Differenzen überwiegen aus unserer Sicht. Die Software Craftsmen sehen sich als Gegenentwurf zum Software Engineer. Sie glauben nicht mehr an eine systematische, ingenieurmäßige Softwareentwicklung. Für sie ist eine grundsätzlich andere Herangehensweise wichtig, eben eine handwerkliche. Damit nehmen sie wieder, wie schon XP und Scrum, den Prozess in den Blick. Wie nun genau das Werk eines Software Craftsman aussehen soll, das bleibt merkwürdig unklar. Bei allem Willen zu mehr Qualität sind die Software Craftsmen für uns daher zu unkonkret. Außerdem haben wir nichts gegen den Versuch, systematischer oder gar industriemäßiger zu werden. Der Titel "Software Engineer" lässt sich aus unserer Sicht sinnvoll mit Leben füllen.

Schließlich ist Softwarequalität das Thema von Verbänden und Normen. Da kann man sich ISO-zertifizieren lassen oder sich auf ein CMMI-Level heben. Das ist alles schön und gut. Nur sehen wir nicht, dass diese Initiativen auf breiter Front Erfolg haben. Der Entwickler einer Branchensoftware in einem 5-Mann-Team hat davon sogar wahrscheinlich nicht einmal gehört. Ganz zu schweigen davon, dass seine kleine Softwareschmiede eine Zertifizierung wegen der hohen Kosten nicht durchlaufen würde. Die "große", "formale", "offizielle" Softwarequalität lässt also eine sehr große Zahl von Projekten außen vor, weil sie bürokratisch und teuer ist.

Mit Clean Code Developer wollten wir daher eine Lücke schließen, die wir in unserer Arbeit in vielen Projekten gesehen haben. Es geht uns "nur" um eine ganz pragmatische und vor allem innere Softwarequalität, die sich mit etwas gutem Willen und ein paar Werkzeugen in jedem Projekt herstellen lässt. Von anderen Initiativen unterscheiden wir uns also schon einmal durch unseren Fokus.

Darüber hinaus legen wir Wert auf die Didaktik. Denn der schönste Fokus nützt nichts, wenn sich das Ziel nicht erreichen lässt. Clean Code Developer unterscheidet sich unserer Meinung nach daher von anderen Initiativen durch sein Stufenkonzept. Wir haben den "Lernstoff" von vornherein eingeteilt, sodass ein klarer Weg hindurch sichtbar ist. Wir holen die Entwickler bei ihrer Überlastung ab und zeigen ihnen, wie sie in kleinen Schritten – definiert in den CCD-Graden – zu einer Veränderung ihrer Haltung und damit zu höherer Codequalität kommen.

heise Developer: Warum scheint es gerade jetzt dafür das Bestreben zu geben, dass solche Initiativen verstärkt aufkommen?

Westphal: Softwarequalität im Allgemeinen ist natürlich kein neues Thema. Es gibt – wie gesagt – viele Initiativen, die sich damit auf die eine oder andere Weise auseinander setzen. Auch an Literatur mangelt es nicht. Und doch: Irgendwas ist heute anders.

Ich denke, wir haben eine kritische Masse an Legacy-Code überschritten. Dazu kommen immer anspruchsvollere Kunden. Und die Technikanbieter treiben uns noch mehr als früher zu Veränderungen. Ergo: In weniger Zeit ist immer mehr zu erledigen, dadurch stolpern Teams deutlicher als bisher über den Haufen "technical debt", den sie aufgetürmt haben. Früher sind wir sozusagen vom 1-Meter-Brett ins Wasser gehüpft; da ist ein Sprung von schlechter Qualität kein Problem. Jetzt hingegen springen wir vom 10-Meter-Brett und tun gut daran, wirklich sauber zu springen, denn ein Bauchklatscher kann tödlich sein.

Schließlich ist Bewusstheit – und um nichts anderes geht es bei Clean Code Developer – immer auch eine Sache des Alters. Es gehört zum Entwicklungsprozess. Die Branche kommt langsam aus der Pubertät heraus. Wir entwickeln einen Blick über uns und den Moment hinaus. Angefangen hat das aus meiner Sicht mit der Pattern-Bewegung Mitte der 1990er. Sie hat jenseits akademischer Kreise einen Schritt zurück gemacht und abstrahiert. Die Agilitätsbewegung war der nächste Schritt. Und jetzt geht es um innere Qualität, um Nachhaltigkeit.

Auch bei Clean Code Developer geht es um Patterns im weitesten Sinn, um Best Practices. Voraussetzung dafür sind jedoch Daten, in denen man überhaupt Muster erkennen kann. Was führt zum Erfolg, was ist kontraproduktiv? Die Datenlage ist anscheinend erst seit vielleicht etwas mehr als fünf Jahren ausreichend, um akzeptable Muster nicht nur zu sehen, sondern auch verbreiten zu können. Wir haben damit vielleicht 20 bis 30 Jahre im Allgemeinen an massenhafter Softwareentwicklung gebraucht und 15 Jahre Objektorientierung und Rapid Application Development (RAD). Das halte ich für verständlich.