Code Ownership (II)

Bild: Unsplah / Peter Gombos - Lizenz

Dass Code Ownership schlecht ist ist klar. Wenn nur ein einziger Entwickler den Code bearbeiten darf besteht ein großes Risiko sobald er krank wird oder kündigt. Der neue Code Owner muss sich einarbeiten bevor er weiterentwickeln kann, dadurch geht Zeit verloren und dadurch Produktivität und Geld. Schlimmstenfalls muss unverständlicher Code komplett neu geschrieben werden. Wenn ein Entwickler Anspruch auf Code Ownership erhebt sollte es daher die Aufgabe von jedem anderen Mitarbeiter sein zu widersprechen. Was aber wenn dieser Anspruch gar nicht erhoben wird und Code Ownership trotzdem entsteht? Gibt es diese Situation überhaupt? Ja, es gibt sie.

Ein Beispiel dafür kann sein, dass Teile einer Anwendung in einer eher unbekannten, obskuren oder schlecht angesehenen Programmiersprache verfasst werden, etwa in Clojure, Whitespace oder Coffeescript. Die meisten Entwickler werden von sich aus darauf verzichten sich damit zu befassen, wodurch die verbleibenden automatisch zu Code Ownern werden, die im Zweifel nur schwer zu ersetzen sind. Für diese Situation gäbe es verschiedene Lösungen: man kann festlegen, dass nur Sprachen benutzt werden sollen die von einer ausreichenden Zahl von Entwicklern verstanden werden, man kann andere in neuen Sprachen schulen oder man kann vorgeben in welchen Sprachen programmiert werden soll.

Ein anderer Fall liegt vor wenn alte Anwendungen nicht mehr weiterentwickelt sondern nur noch von den an der Entstehung beteiligten "am Leben erhalten werden". Neue Entwickler müssen sich damit gar nicht mehr befassen, da "das ohnehin irgendwann abgeschafft wird". Wenn dieses "Irgendwann" sich dann unerwartet lange zieht kann die Verrentung der älteren Mitarbeiter zum Problem werden: ausser ihnen kennt niemand mehr den alten Code, der auch keinen modernen Standards mehr entspricht. Ein aktuelles Beispiel solcher "Alters-Code Ownership" ist die Flugsicherungs-Software am Flughafen Paris Orly. Die Lösung hierfür ist Common Sense - niemand sollte Systeme benutzen die zwanzig Jahre und älter sind.

Zuletzt kann es auch "sozial bedingte Code Ownership" geben. Wenn ein Entwickler für die anderen so unangenehm ist, dass sie die Zusammenarbeit mit ihm meiden (sei es wegen schlechtem Benehmen, schlechter Körperhygiene oder sonstigen Gründen), dann kann es vorkommen dass er beabsichtigt oder unbeabsichtigt Code schreibt den nur er selbst lesen kann. Ein vergleichbares Phänomen tritt auf wenn einer von den anderen ausgegrenzt oder gemobbt wird und er deswegen alleine arbeiten muss oder will. In der Behebung ist das der vermutlich schwierigste Typ, da nicht jeder Mensch bereit oder in der Lage ist sein Verhalten zu ändern. Lösungen hierfür könnten Mediation sein, Coaching, moderiertes Feedback oder im schlimmsten Fall disziplinarische Maßnahmen.

In jedem dieser Fälle ist es wichtig, dass erkannt wird, dass die jeweilige Situation Code Ownership zur Folge hat, mit allen bekannten Folgen. Selbst wenn die Situation bisher aus irgendeinem Grund nicht thematisiert wurde - spätestens jetzt sollte das geschehen, da sonst unkalkulierbare Geschäftsrisiken entstehen können.