Vor zwei Wochen habe ich begonnen, mich ausführlich mit Extreme Programming zu beschäftigen, nicht zuletzt deshalb, weil diese Methodik – zumindest in weiten Teilen –meine persönliche Vorgehensweise widerspiegelt.
Als essenziell wird im Extreme Programming die Einhaltung von Programmierstandards angesehen, da diese als Rahmen für die gemeinsame Verantwortlichkeit aller Entwickler für den geschriebenen Code fungieren.
In einer Diskussion mit Peter Bucher zu diesem Thema kamen wir zu dem Schluss, dass es für uns beide nur schwer vorstellbar ist, nach gänzlich anderen als den von uns eingehaltenen Programmierstandards zu entwickeln. Aus dieser Feststellung resultierte schließlich die Frage, warum uns Standards und deren Einhaltung eigentlich so wichtig sind.
Ich für meinen Teil möchte folgende Antwort auf diese Frage geben: Im Mai 2009 hatten Peter und ich das Thema Woran erkennt man einen guten Entwickler? für unser Streitgespräch ausgewählt. Als wesentlich habe ich damals zwei Eigenschaften genannt:
- Smart: Zum einen muss er “smart” sein. Joel Spolsky meint damit, dass ein guter Entwickler kreativ, aufgeschlossen und neugierig sein muss, dass er zudem bereit sein muss, ungewöhnliche Wege zu gehen, und dabei gleichzeitig in der Lage, gegebenenfalls um eine Ecke mehr zu denken als ein durchschnittlicher Entwickler.
- Gets Things Done: Zum anderen muss er seine Aufgaben allerdings auch erledigt bekommen – und zwar in der vorgegebenen Zeit. Denn all die zuvor genannten positiven Eigenschaften nützen nichts, wenn es einem Entwickler nicht gelingt, auf den Punkt zu kommen und seine Aufgaben zeitgemäß abzuschließen.
Beide Forderungen gehen dabei auf Joel Spolsky und sein Buch Smarts and Gets Things Done zurück. Ralf Westphal hat meinem damaligen Blogeintrag kommentiert und strengere Kriterien gefordert:
Auch wenn ich Joels Kriterien "smart" und "gets things done" gut finde, so sehe ich nicht, dass er damit einen guten Entwickler charakterisiert. Sie sind für ihn nötige, aber keine hinreichenden Beschreibungen. Er benutzt sie ja auch vor allem in Bezug auf die Bewerberauswahl. Da hilt es nämlich, nicht nach dem perfekten Kandidaten zu suchen, sondern sich schon mit einem smarten, der seine Aufgaben auch erledigt, zufrieden zu geben.
Das ist aber nur der Anfang! Denn wenn einer nur smart und verlässlich ist, dann ist er noch lange nicht produktiv. Er muss womögl erst noch lernen, seine Smartness und Verlässlichkeit mit den relevanten Werkzeugen und Materialien einzusetzen.
Ich muss zugeben, dass Ralf damit vollkommen recht hat: Angesprochen und explizit charakterisiert wird dadurch nämlich nur auf die äußere Form der Arbeit – die innere hingegen bleibt verschwommen.
Deshalb möchte ich heute nachlegen und bei dieser Gelegenheit auch direkt die Frage beantworten, warum Peter und mir Standards und deren Einhaltung so wichtig sind.
In dem Computerspiel Quake III Arena gab es einige Auszeichnungen, die man als Spieler erreichen konnte. Eine davon war Accuracy, die für eine Trefferquote von über 50% verliehen wurde. Laut dict.cc bedeutet dieses Wort außer Treffsicherheit und Treffgenauigkeit auch Exaktheit und Sorgfalt.
Und genau damit bezeichnet Accuracy eine aus meiner Sicht ausgesprochen wichtige Anforderung an einen Entwickler: Die Liebe für Details, und die Fähigkeit, auch auf jeden Punkt und jedes Komma zu achten – und nicht nur oberflächlich mal eben schnell über Code hinweg zu gehen.
Interessanterweise verfügen alle Entwickler, die ich kenne und deren Arbeit ich schätze, über diese Eigenschaft – sich nicht mit dem Erstbesten zufrieden zu geben, sondern nachzuhaken und genau hinzusehen. Das merkt man dann nicht nur an der Art, wie Code geschrieben wird, sondern beispielsweise auch daran, wie Code gedebuggt wird.
Für diese Entwickler sind Programmierstandards dann nämlich kein lästiges Hindernis, das es einzuhalten gilt, sondern ein hilfreiches Rahmenwerk für die äußere Form, das es ermöglicht, sich auf das Wesentliche zu konzentrieren.
Aus diesem Grund erachten auch Peter und ich Programmierstandards als dermaßen wichtig: Sie erfüllen eben nicht nur die im Extreme Programming verfolgte Intention, gemeinsame Verantwortlichkeit zu etablieren, sondern ermöglichen uns auch, den Code des anderen schneller zu verstehen und uns gegenseitig zu helfen.
Die spannende Frage ist: Lässt sich diese Liebe zum Detail erlernen, oder ist sie – zumindest zu einem gewissen Grad – angeboren?