Code Ownership (III)

Bild: Unsplash / Desola Lanre-Ologun - Lizenz

Was hatten wir bereits? Erstens: Code Ownership ist schlecht. Und zweitens: Code Ownership kann auch versehentlich entstehen. Was bleibt noch? Vieles, an dieser Stelle aber zunächst ein weiterer Fall - Code Ownership durch eine Gruppe, beispielsweise durch ein Entwicklungsteam. Auch das ist ein Antipattern, wenn auch ein weniger offensichtliches (und natürlich eines das nur da ein Thema ist, wo es mehr als ein Team gibt).

Zunächst einmal ist der Bus-Faktor relativ gering, da nicht ein Entwickler das "Wissensmonopol" auf einen Code-Abschnitt besitzt sondern mehrere. Wenn also der Fall eintritt, dass ein Team-Mitglied von einem Bus angefahren wird und ausfällt können die anderen einspringen. Das offensichtlichste Risiko von Code Ownership ist demnach nicht gegeben. Warum soll dieser Fall dann trotzdem problematisch sein? Aus den folgenden Gründen:

Auch Gruppen-Code Ownership erzeugt immer einen Flaschenhals. Wenn beispielsweise nur eines von vier Teams an der Entwicklung des CRM-Teils einer Anwendung beteiligt war, dann tritt ein Problem auf wenn z.B. gegen Ende eines Projekts nur noch CRM-Funktionen zu entwickeln sind. Die anderen Teams müssen sich in diesem Fall neu in diesen Bereich einarbeiten, was Zeit und Geld kostet. Umgekehrt ist das CRM-Team nur eingeschränkt in der Lage einzuspringen wenn etwa das Search-Team von einer Grippewelle ausser Gefecht gesetzt wird.

Gruppen-Code Ownership erzeugt oft eine suboptimale Architektur. Bleiben wir beim Beispiel des CRM-Teams. Mit großer Wahrscheinlichkeit wird es (bewusst oder unbewusst) alle die Kunden betreffenden Funktionen im eigenen Teil der Anwendung einbauen, selbst wenn sie eigentlich im User Management oder im Checkout mehr Sinn gemacht hätten. Mögliche Gründe dafür sind, dass man nicht auf eine Zulieferung des anderen Teams warten will oder dass man schlicht nicht weiss, dass diese Funktion an anderer Stelle mehr Sinn machen würde (durch die Code Ownership ist diese andere Stelle einfach nicht bekannt).

Eine weitere häufige Folge von Gruppen-Code Ownership ist eine schlechte Absicherung der Gesamtanwendung durch Tests. Den eigenen Bereich abzusichern und stabil zu halten ist im eigenen Interesse, aber übergreifende System- oder End to End-Tests? Wer nur für einen Teil des Ganzen zuständig ist wird die Zuständigkeit dafür nicht zwingend bei sich sehen und selbst wenn doch - die fehlende Kenntnis der restlichen Anwendung wird es schwer machen zu erkennen wo Bedarf besteht und wo nicht.

Eine globale Shared Code Ownership, also gemeinsame Zuständigkeit und Weiterentwicklung aller Anwendungsteile durch alle Entwickler, kann diesen Fehlentwicklungen entgegenwirken. Natürlich erfordert das ein höheres Mass an Verantwortungsbewusstsein und Kommunikation, allerdings ist das angesichts des Gewinns an Qualität und Stabilität ein vertretbarer Preis.