Code Ownership

Gründe für Code Ownership

Es gibt verschiedene Gründe, warum Unternehmen eine Code Ownership definieren. Hier finden Sie eine Auswahl:

• Code-Eigentümer sind oftmals mit dem Code, den sie verantworten, vertraut. Sofern innerhalb der Organisation Klarheit darüber herrscht, wer für welche Codebasis die Verantwortung trägt, vereinfacht das die interne Kommunikation und häufig auch den Wissensaustausch untereinander.
• Übernimmt ein Team die Verantwortung für eine Codebasis, führt das oft zu einer verbesserten Zusammenarbeit im Team, insbesondere wenn eine Kultur des Miteinanders gelebt und der gemeinsame Wunsch und Anspruch für qualitativ hochwertige Software existiert.
• Ist ein Entwickler oder ein Entwicklungsteam für den Code verantwortlich, steigt die Identifikation mit der Aufgabe und dem Ergebnis. Idealerweise verbessert dies auch die Qualität des Codes, minimiert Fehler und erleichtert die Wartbarkeit des Codes.
• Mit dem Code Ownership geht bei den Beteiligten meist eine Motivationszunahme einher. Diese kann bspw. dazu beitragen, technische Schulden zu minimieren oder zu vermeiden, die Code Coverage und die Sicherheit des Code zu verbessern oder innovative Ansätze auszuprobieren.

In manchen Publikationen ist zu lesen, dass Code Ownership auch zu einer verbesserten Dokumentation des Codes führt – evtl. ist das aber nur Wunschdenken.

Arten von Code Ownership

Es gibt verschiedene Arten von Code Ownership¹:

• Strong Code Ownership,
• Weak Code Ownership und
• Collective Code Ownership.

Strong Code Ownership – “strong” steht für “stark” – bezieht sich auf die Aufteilung einer Codebasis und die Zuweisung einzelner Entwickler zu diesen Abschnitten. Jeder Entwickler trägt die volle Verantwortung für seinen Teil, d. h. er ist für die Pflege und Qualität des Codes verantwortlich. Er agiert als Gatekeeper, sodass Entwickler, die Änderungen am Code vornehmen wollen, der ihnen nicht gehört, eine entsprechende Genehmigung des Code-Eigentümers einholen müssen. Natürlich ist er auch die Person, an die sich andere Entwickler wenden, wenn es ein Problem mit seinem Code gibt.

Strong Code Ownership wirkt organisiert, kann aber in der Praxis auch kontraproduktiv sein. Ist der Code Owner aufgrund von großer Arbeitslast, Urlaub oder Unternehmensaustritt schwer oder gar nicht erreichbar, dann entstehen Engpässe. Schritt für Schritt häufen sie Änderungsanfragen, was die Menge unfertiger Arbeit erhöht und die Entwicklungsgeschwindigkeit reduziert. Kurzum: Strong Code Ownership ist relativ einfach, stößt aber zügig an seine Grenzen.

Weak Code Ownership – “weak” steht für “schwach” – hat einige Ähnlichkeiten mit Strong Code Ownership. Das Modell der schwachen Codeverantwortung teilt ebenfalls die Codebasis auf und weist den Entwicklern bestimmte Teile davon zu. Der Hauptunterschied besteht darin, dass andere Entwickler den Code, der ihnen nicht gehört, direkt ändern dürfen, anstatt den Weg über den Eigentümer zu nehmen.

Auch wenn eine schwache Code-Eigentümerschaft mehr Freiheiten als das “starke” Modell zulässt, bedeutet dies nicht, dass die Code-Eigentümer frei von Verantwortung sind: Codebesitzer sind weiterhin für die Pflege und Qualität des zugewiesenen Codes verantwortlich, und müssen sich der Änderungen bewusst sein, die andere Entwickler vornehmen. Obwohl die Code-Eigentümer die Änderungen nicht selbst vornehmen müssen, werden sie dennoch benötigt, um die von anderen Entwicklern vorgenommenen Änderungen zu überprüfen und zu genehmigen.

Oftmals wird das Modell der schwachen Code-Eigentümerschaft dem Modell der starken Code-Eigentümerschaft vorgezogen, da es die Beiträge zum Quellcode und die Zusammenarbeit zwischen den Teammitgliedern erhöht, idealerweise ohne die Qualität des Codes zu beeinträchtigen. Es erweist sich auch als effizienter und verringert den Arbeitsaufwand für die Code-Eigentümer; die Teammitglieder müssen den Eigentümer nicht mehr bitten, die Änderungen vorzunehmen, sondern können dies direkt tun.

Dieses Modell ist dann nützlich, wenn man zu einem größeren Team arbeitet, das viele andere gemeinsame Aufgaben verfolgt. Da der Code-Eigentümer jedoch weniger stark an den Code gebunden ist, lässt sich in der Praxis auch immer wieder ein Verantwortungsmangel beobachten, der leider mit Qualitätsverlusten einhergeht. Zudem steigt die Verwirrung, wenn nicht wirklich klar ist, wer für die Durchführung von Änderungen und die Aktualisierung des Codes verantwortlich ist. Und das führt ggf. zu Konflikten in der Zusammenarbeit und zur Produktivitätsverlusten: viele Entwickler beschäftigen sich mit der Lösung eines bestimmten Problems, das auch von einem einzigen Entwickler hätte gelöst werden können.

Kurzum: Das Modell der schwachen Codeverantwortung ist eine gute Möglichkeit, die Probleme zu vermeiden, die bei der Verwendung eines starken Codeverantwortungsmodells auftreten. Die Entwickler haben mehr Freiheit, Änderungen vorzunehmen, ohne dass sich die Arbeit für den Codebesitzer auftürmt. Es hat jedoch auch seine Nachteile, so dass es für das Team oder die Mitwirkenden wichtig ist, sich darüber im Klaren zu sein, wer für die Pflege und Qualität des Codes verantwortlich ist.

Collective Code Ownership – sprich kollektiver Codebesitz – unterscheidet sich stark von den beiden bisher genannten Arten. In einem kollektiven Modell – der Begriff stammt aus Extreme Programming, das ein Zusammenwirken von Werten, Prinzipien und Praktiken bei der Entwicklung von Software beschreibt² – gibt es keine individuellen Eigentumsrechte. Die Verantwortung und Verwaltung der Codebasis wird unter allen Teammitgliedern aufgeteilt. Die Teammitglieder dürfen Änderungen an jedem Teil des Codes vornehmen, unabhängig davon, wer ihn ursprünglich geschrieben hat.

Das kollektive Modell ermutigt alle Entwickler, zusammenzuarbeiten, um die Qualität der Codebasis zu verwalten und zu erhalten. Es ist auch zeitsparender und verringert die Arbeitsbelastung, da alle Teammitglieder ihren Beitrag leisten und den Code überprüfen können, im Gegensatz zu einer einzelnen Person oder einer kleinen Gruppe von Personen. Mit anderen Worten, es ist einfacher und schneller, Verbesserungen vorzunehmen und Fehler zu beheben.

Doch so effizient dies auch klingt, das kollektive Modell hat auch seine Nachteile: Da individuelle Eigentumsrechte fehlen, sind einige Entwickler möglicherweise nicht mit einigen Teilen der Codebasis vertraut, was zu Wissenslücken und möglichen Missverständnissen führt. Außerdem steht kein spezieller Code-Eigentümer zur Verfügung, der die Arbeit mehrerer Teammitglieder verwaltet und koordiniert, was zu Schwierigkeiten bei Struktur und Organisation führt. Außerdem kann sich dieses Modell als kontraproduktiv erweisen, da mehr Besprechungen benötigt werden, um sich mit den anderen Teammitgliedern abzustimmen.

Kurzum: Das Modell der kollektiven Codeverantwortung hat das Potenzial, die Effizienz eines Teams sowie die Qualität und Wartbarkeit der Codebasis zu verbessern. Allerdings ist es essenziell, dass alle Beteiligten auf dem Laufenden sind und klar kommunizieren und verstehen, welche Konsequenzen individuelle Anpassungen haben.

Tipps zur Anwendung von Code Ownership

Hier finden Sie einige Tipps zur Anwendung von Code Ownership:

• Code Ownership kann auf verschiedene Weise implementiert werden. Die beste Art hängt von den spezifischen Bedürfnissen des Teams, den Rahmenbedingungen und Ihrer Organisation bzw. Organisationskultur ab. Legen Sie den Scope bzw. Umfang der Codeverantwortung fest. Entscheiden Sie idealerweise gemeinsam mit allen Beteiligten, ob die Verantwortung einzelnen Personen, ausgewählten Teams oder dem Kollektiv übertragen wird.
• Vermitteln Sie dem Team den Prozess der Codeverantwortung. Vergewissern Sie sich, dass alle Teammitglieder ihre Verantwortlichkeiten kennen und wissen, wie sie die Codeverantwortung verfolgen können.
• Ermutigen Sie die Entwickler, mit den Code-Eigentümern zu kommunizieren. So können Sie sicherstellen, dass die Code-Eigentümer über alle Änderungen an der Codebasis informiert sind.
• Dokumentieren Sie die Vereinbarungen. Und – quasi selbstredend – verwenden Sie ein Versionsmanagement und führen Sie Code Reviews durch.

Hier sind einige zusätzliche Tipps für die Einführung von Code Ownership:

• Wenn die Codeverantwortung für Sie neu ist, beginnen Sie damit, die Codeverantwortung für einige wenige wichtige Dateien oder Module zu übernehmen. So können Sie ein Gefühl dafür bekommen, wie der Prozess funktioniert, bevor Sie ihn ausweiten.
• Der Code Ownership-Prozess sollte so flexibel sein, dass er sich an die sich ändernden Anforderungen des Teams anpassen lässt. So kann es z. B. sinnvoll sein, den Umfang der Codeverantwortung oder die Nachverfolgungsmethode zu ändern, wenn das Team wächst oder sich verändert.
• In vielen Organisationen benötigt Code Ownership Zeit, bis das Konzept Fuß fasst. Erwarten Sie nicht, dass Sie sofort Ergebnisse sehen. Kommunizieren Sie den Prozess einfach weiter und ermutigen Sie die Entwickler, ihn zu befolgen.

Und zu guter Letzt: bleiben Sie am Ball, denn wenn es gelingt, Code Ownership effektiv zu leben, steigt die Qualität, die Korrektheit und die Wartbarkeit Ihrer Software.

Herausforderungen beim Collective Code Ownership

Auch wenn Collective Code Ownership als Konzept zur gemeinschaftlichen Entwicklung von Software gut klingt, so gilt es in der Praxis einige Herausforderungen zu meistern:

• Es passiert bspw. immer wieder in größeren Vorhaben, dass sich “nur” ein Entwickler für einen Teilbereich verantwortlich fühlt und entsprechend auch alleine agiert. Dies führt fast automatisch zu einem Wissens-Silo und ggf. zu einer Abhängigkeit von dem Entwickler.
• Der Aufwand zum Austausch von Wissen nimmt unweigerlich zu. Gleichzeitig kann die Wertschöpfung pro Entwickler abnehmen.
• Entwickler sind auch nur Menschen, d. h. sie arbeiten gerne mit Kollegen und Kolleginnen zusammen, die sie mögen. Ohne Koordination durch eine Entwicklungsleitung kann das dazu führen, dass immer dieselben Personen zusammenarbeiten und so Wissens-Inseln entstehen. “Außenstehenden” Beteiligten fällt es entsprechend schwer, mitzuwirken.
• Sind mehrere Entwickler für denselben Code verantwortlich, kann es schwierig sein, im Nachgang festzustellen, wer was aus welchen Gründen getan hat oder wer für einen bestimmten Fehler oder ein bestimmtes Problem verantwortlich ist. Es kommt zu einer Verantwortungsdiffusion, die leicht zu erhöhten Aufwänden (und Schuldzuweisungen) führt.
• Denkbar ist auch, dass die gemeinsame Verantwortung dazu führt, dass einzelne Entwickler zögern, Änderungen vorzunehmen, da sie unbeabsichtigte Folgen und negative Reaktionen anderer befürchten.

In manchen Publikationen ist zu lesen, dass es ohne eineindeutige Verantwortlichkeiten schwierig sein kann, konsistente Codierungsstandards und -praktiken in der gesamten Codebasis aufrechtzuerhalten. Ob das aber wirklich an dem Code Ownership liegt, ist eher umstritten. Die Meinungen variieren auch, ob ein Gleichgewicht zwischen einer kollektiven Verantwortung für den Code und der individuellen Verantwortung für “kritische” Bereiches des Codes von verantwortlichen Einzelpersonen oder kleineren Gruppen nützlich und erstrebenswert ist.

Könnte Code Ownership zu einer reduzierten Produktivität führen oder zu Overengineering beitragen?

Hinweise:

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Hier finden Sie eine Einschätzung zu den Code Ownership Arten von Martin Fowler, einem der Autoren und Erstunterzeichner des Agilen Manifests.
[2] Extreme Programming verwendet als Methode inzwischen den Begriff “Shared Code”. Felix Stein propagiert zudem in einer vierteiligen Beitragsserie ein Continuous Code Ownership, da es nicht ausreicht, sich nur im Zuge von anstehenden Modifizierungen mit dem Code zu beschäftigen, da es in der Praxis oftmals mehrere Jahre dauern kann, bis ein bestimmtes Stück Code angefasst wird.

Wir suchen Softwareentwickler. Berufseinsteigerinnen, Entwickler mit einigen und Expertinnen mit vielen Jahren Erfahrung.

Und hier finden Sie ergänzende Informationen aus Wissen kompakt:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.