(Collective) Code Ownership neugedacht - Über Risiken der Wissensverteilung am Beispiel der Corona-Warn-App - Cape Of Good Code

Geschrieben von Egon Wuchner | 16.03.21 00:10

Zuerst veröffentlicht auf Informatik-Aktuell: Teil1 & Teil2.

Als Projektverantwortlicher für eine Softwareentwicklung

  • Kennen Sie als ihre Teamstruktur?
  • Wissen Sie, wer woran arbeitet?
  • Wissen Sie, ob der/die jeweilige Entwickler:in die besten Wissensvoraussetzungen hat?

“Müssen Sie nicht”, sagen die Befürworter einer agilen Entwicklung, denn “das Team organisiert sich selbst”. Und übrigens herrsche das Prinzip der “Collective Code Ownership“, d. h. jeder sei für alles verantwortlich im Code [1].

Mit etwas Nachdenken kommt man ins Grübeln, z. B. weil “Collective Code Ownership” dem Prinzip der Modularisierung und effizienten Entwicklung widerspricht [2].

Aber das Prinzip ist nicht nur zweifelhaft, es richtet auch Schaden an. Es tritt u. A. das “Diffusion of Responsibility”-Phänomen ein [3], bei dem sich keiner mehr so richtig verantwortlich fühlt. Einzelne Entwickler:innen verlieren den Durchblick, weil viele der Kolleg:innen den gleichen Code mit verändert haben.

Dabei vermischen sich die verschiedenen Entwicklungsstile zu einer Code-Kakophonie, und der kognitive Aufwand zum Verstehen des Codes steigt bis zur Nichtnachvollziehbarkeit an.

Wie wahr ist doch, dass viele Köche den Brei verderben können! Eine Erosion der Qualität des Arbeitsergebnisses wird unvermeidbar und letztlich daran erkennbar, dass eskalierende Bugfixing-Aufwände auftreten.

Nun ist es naheliegend nach den Alternativen zum “Collective Code Ownership” zu fragen.

  • Was sind stattdessen gute Verantwortungs- und Wissensverteilungen in einem (agilen) Team?
  • Woran erkennt man früh genug, dass ein Team nicht (mehr) effektiv zusammenarbeitet?
  • Welche weiteren Alarmsignale gibt es für problematische Projekte und was sind die Antworten darauf?

Wir werden in diesem Artikel keine rein theoretischen Betrachtungen anstellen, sondern die deutsche Corona-Warn-App als aktuelles und relevantes Beispiel analysieren. Dabei haben wir die Wissensstrukturen der beiden iOS- und Android-Entwicklerteams Schritt für Schritt untersucht, um gute und risikobehaftete Muster wie z. B. Knowledge Balances, Knowledge Islands und Knowledge Tangles zu erkennen. Erfahrungsgemäß lassen sich die Schlüsse und Empfehlungen aus einer solchen Analyse sowohl von selbstorganisierten Softwareteams, als auch von Projektverantwortlichen für eine effektivere Zusammenarbeit und Führung nutzen.

Mehr Insights zur Architektur-Qualität der Corona-Warn-App gibt es in unseren Blog unter: Corona-Warn-App – Auf dem Weg zu kritischen Technischen Schulden?

1. Risiken durch Austausch der Entwicklerteams

Die beiden Apps (iOS und Android) werden von zwei unterschiedlichen Entwicklerteams entwickelt, was angesichts der unterschiedlichen Technologien wie Programmiersprachen und verwendeten Bibliotheken sinnvoll erscheint. Überraschend weist die Auswertung unserer Analysedaten auf einen Austausch des gesamten Entwicklerteams während des Jahres 2020 hin. Das trifft sowohl auf die iOS- als auch auf die der Android-App zu. Diese Schlussfolgerung leiten wir aus der zeitlichen Entwicklung zweier Analyse-Informationen ab:

  1. Anzahl der Commits pro Entwickler:in über die Zeit (Abb. 1) und
  2. Vergleich der anonymisierten Entwicklerlisten über die Zeit.

Abb. 1 zeigt die Anzahl der Commits in das GitHub Code-Repository von Quartal 2 bis Quartal 4 des Jahres 2020 für die iOS-App-Entwicklung.

Abb. 1: Zeitreihe der Commits pro Entwickler in Q2-Q4/2020 der iOS-App-Entwicklung

In Abb. 1 lassen sich drei wesentliche Stellen auf der X-Achse ausmachen:

  • links die Commits im 2. Quartal 2020 (Q2)
  • rechts die Commits im 4. Quartal 2020 (Q4) und
  • in der Mitte die Commits zwischen den Quartalen (3. Quartal 2020 (Q3))

Es wird sofort ersichtlich, dass die Anzahl der Commits in Q3 am geringsten war, was mit der Urlaubszeit im Sommer erklärt und somit als normal eingestuft werden kann. Wirklich auffallend ist aber, dass die Mitglieder der Teams in Q2 völlig andere sind als die in Q4, was an den unterschiedlichen Farben erkennbar wird (jede Farbe ist einer/m spezifischen Entwickler:in zugeordnet). Über die Gründe für den Austausch haben die Autoren keine Kenntnis.

Es mag vereinzelt Entwickler:innen geben, die durchgehend von Q2 bis Q4 Teil der Entwicklung waren, aber die Akteure mit den meisten Commits sind vor und nach der Sommerzeit nicht die gleichen. Wenig überraschend wäre es, wenn der Verlust an bestehendem Projektwissen zunächst mit einem erheblichen Rückschlag in der Projekteffizienz einherging.

Im Folgenden fokussieren wir unsere Analysen und Aussagen, wenn nicht anders beschrieben, auf den Entwicklungsstand der Corona-Warn-App, der in Q4 2020 vorlag.

2. Auffallende Wissensinsel in den Teams

Des Weiteren wurde die Verteilung der Entwicklungsaufwände pro Entwickler:in für beide Apps betrachtet (zur Erläuterung der Messung des Entwicklungsaufwandes sei auf [4] verwiesen).

Bei der Betrachtung der Abb. 2 (linkes Teilbild) fällt auf, dass über die Hälfte des Android-Entwicklungsaufwands auf eine:n Entwickler:in entfällt (insgesamt sind 28 Entwickler:innen beteiligt). Das deutet auf eine stark ausgeprägte Wissens-/Fähigkeiteninsel hin, die aus einer/m einzigen Entwickler:in (committer41) besteht. Das ist nicht nur für ein Produkt wie die Corona-Warn-App, mit seiner enormen sozioökonomischen Relevanz sehr kritisch. Ein Ausfall dieses Committers könnte Folgen mit problematischer Tragweite haben. Es bleibt zu hoffen, dass es sich bei dieser/m “Star”-Entwickler:in nicht auch noch um eine:n externe:n Mitarbeiter:in handelt.


Abb. 2: Vergleich der Entwicklungsaufwände zwischen Android- (links) und iOS-Entwickler:innen (rechts) in Q4/2020

Der Befund für die iOS-Entwicklung (Abb. 2, rechtes Teilbild) ist etwas besser, aber die Aufwände sind ebenfalls nicht sehr ausgewogen verteilt. Nur 3 von 21 Entwickler:innen machen mehr als 61 Prozent des Entwicklungsaufwandes aus. Dabei spielt committer62 auch noch eine eigenständige Rolle als Tester:in. Idealerweise verteilen sich die Aufwände der Testentwicklung auf viele Entwickler:innen. Unter Berücksichtigung dieses Aspekts ist ein Entwicklungsaufwand von über 50 Prozent nur noch zwei Entwickler:innen (committer2 und committer24) zuzuweisen.

Die Autoren empfehlen die Analyse der Entwicklungsanteile Einzelner regelmäßig zu messen (das ergibt sich nicht aus den abgerechneten Stunden!), um das Risiko von Personenabhängigkeiten rechtzeitig zu erkennen und gegensteuern zu können.

3. Fragen zur Effektivität der Wissensverteilung

Man wird Gründe oder Zwänge gehabt haben, um einen so umfangreichen Austausch in den Projektteams vorzunehmen. Ob das erhoffte Ergebnis sich eingestellt hat, können wir auch nicht aus der Ferne einschätzen. Folgende Fragen sollten sich die Teams und Projektverantwortlichen stellen:

  1. Ist die aktuell unausgewogene Aufwandsverteilung unkritisch oder sollte man zeitnah gegensteuern?
  2. Ist das Entwicklungs-Wissen dennoch so verteilt, dass für das Projekt kein größeres Risiko besteht?
  3. Arbeiten die Entwickler:innen nach dem Austausch so gut zusammen, dass das Team auch effektiv und wertschöpfend entwickelt?
  4. Welche Muster der Wissensverteilung und welche Auswirkungen sind erkennbar?

4. Beurteilungskriterien für die Team- und Wissensstruktur

Die grundsätzlich Herausforderung bei jedem Entwicklungsprojekt ist die Sicherstellung einer effektiven und robusten Team- und Wissensstruktur. Nach mehreren Untersuchungen haben wir festgestellt, dass Zweier-Teams intuitiv eine gute Art des Knowledge-Sharing und der Wissensstruktur entwickeln [5]. Wir bezeichnen dieses Muster, wenn genau zwei Entwickler:innen an einer nicht zu kleinen gemeinsamen Menge an Quelldateien arbeiten, als “Knowledge Balance“. Eine solche ideale Verteilung von Wissen und Können ergibt sich in der Realität nicht immer zwangsläufig und wird auch nicht immer gesucht. Wir empfehlen deshalb, diesen Aspekt bei größeren und dringenden Projekten rechtzeitig zu analysieren. Aus unseren Analysen und Erfahrungen haben wir in Tabelle 1 einige Muster (Knowledge Patterns) der Wissensverteilung zusammengestellt:


Tabelle 1: Knowledge Patterns und Erläuterungen

Zur visuellen Erkennung dieser Muster der Wissensverteilung nutzen wir Netzwerkdiagramme aus den Daten der DETANGLE-Analyse. Die Diagramme erlauben erste qualitative Hinweise zu möglichen Herausforderungen hinsichtlich einer zu inhomogenen Wissensverteilung. Abb. 3 zeigt ein Beispiel für die iOS Corona-Warn-App in Q4/2020.

Abb. 3: Netzwerkdiagramm zeigt den Zusammenhang zwischen Quellcode-Dateien und Entwickler:innen (Committern) für iOS und Q4/2020

Quellcode-Dateien werden dabei als Rechtecke dargestellt, Entwickler (Committer) sind als Kreise abgebildet. Eine Kante zwischen einem Entwickler und einer Quellcodedatei bedeutet, dass der Entwickler an der Datei im besagten Zeitraum gearbeitet und Änderungen durchgeführt hat.

Die Diagramme sind angesichts von mehr als 20 Entwickler:innen ohne weitere Filter recht unübersichtlich. Trotzdem sticht leicht erkennbar die erwähnte große Wissensinsel (committer62, oben Mitte) hervor. Des Weiteren kann man durch die Abb. 3 und 4 die Zahlen zur bereits erwähnten Aufwandsverteilung, dass committer2committer62 und committer24 mehr als 61 Prozent des Entwicklungsaufwandes bei der iOS-App-Entwicklung ausmachen, bestätigen

Abb. 4: Grün umrandete Dateien wurden von committer2 in Q4/2020 bearbeitet

Abb. 5 zeigt das Netzwerkdiagramm für die Android-Variante der Corona-Warn-App. Auch hier lassen sich Wissenskonzentrationen als Cluster in der Mitte und am Rand leicht ausmachen. Der visuelle Eindruck von Wissensinseln wird durch die Zahlen zur inhomogenen Aufwandsverteilung (Abb. 2) bestätigt. Diese Aufwands- und Wissensverteilungsanalysen sollten im Bereich des Software-Engineering zu den Projekt-KPIs gehören. Sie ermöglichen es, Ursachen für Projektrisiken frühzeitig zu identifizieren und entsprechend gegenzusteuern.

Abb. 5: Netzwerkdiagramm für den Zusammenhang zwischen Quellcode-Dateien und Entwickler:innen (Committern) für Andoid und Q4/2020

5. Bewertung der Effektivität der Wissensverteilung

Um geeignete Gegenmaßnahmen ergreifen zu können, muss aber die Effektivität der vorliegenden Wissensstruktur im Detail beurteilt werden. Dazu werden wir bestimmte Sichten bzw. Filter auf diese Netzwerkdiagramme anwenden:

  • Issue-Typ (z. B. nach Bugs oder Features/Enhancements): Quellcode-Dateien, Entwickler:innen und Kanten werden nur dann angezeigt, wenn an den Dateien nur im Rahmen eines Issues von dem ausgewählten Issue-Typ gearbeitet wurde.
  • Knowledge Patterns: es wird nach gewissen Mustern gefiltert wie z. B. den Knowledge Islands und Knowledge Balances

Eine Wissensverteilung ist dann effektiv, wenn:

  • Entwickler:innen zu einem Ramp-up bzw. zur Wissenserweiterung befähigt werden. Sie sollen über ein anfängliches Bugfixing hinaus einen Kenntnisstand erlangen können, der sie dazu befähigt, in einem hohen Maße zur Implementierung neuer Features beizutragen. Letztendlich sollen so viele Entwickler:innen wie möglich über ein globales Systemwissen verfügen, um selbst Verbesserungen (z. B. Refactorings) im Code oder größere Architekturänderungen eigenständig durchführen zu können.
  • Dabei der nötige Koordinationssaufwand und die anfallenden Kommunikationspfade zwischen Entwickler:innen begrenzt bleiben.
  • Und die anfallenden Entwicklungsarbeiten dennoch soweit wie möglich verteilt und parallel ablaufen können.

Am Ende der Betrachtungsperiode (Q4/2020) war die Mehrzahl der Entwickler:innen (jeweils 15 von 21 bei der iOS-App und 15 von 28 Entwickler:innen bei der Android-App) am Bugfixing beteiligt. Aber einen relevanten Blick bilden die aussagekräftigen Bilder der Featureentwicklung. In Abb. 6 (für iOS) sind Knowledge Islands und Knowledge Balances visuell sehr gut zu sehen.

Aus den Analysedaten ergeben sich folgende Erkenntnisse für die iOS-App und deren Featureentwicklung :

  1. Nur 11 (von 21) Entwickler:innen sind wertschöpfend tätig mit der Entwicklung von Features bzw. Enhancements.
  2. Eine:r der bereits erwähnten Hauptentwickler:innen (committer2) bildet eine große Wissensinsel (rot eingekreist in der Mitte).
  3. Es gibt vier weitere kleinere Wissensinseln (rot eingekreist).
  4. Alle Entwickler:innen arbeiten mit der/m Hauptentwickler:in mehr oder weniger intensiv zusammen und bilden mit ihm kleine oder größere Knowledge Balances (die mit einem grünen Rechteck markiert wurden).
  5. Besagte Hauptentwickler:in (committer2) nimmt die Rolle des Koordinators bei der Featureentwicklung ein.
  6. Abb. 6: Quellcode-Dateien und Entwickler der Feature u. Enhancement Entwicklung (für iOS)

Daher ließe sich qualitativ schlussfolgern, dass neun dieser elf Entwickler jeweils zusammen an der Feature-Entwicklung beteiligt sind. Diejenigen vier, die selber Wissensinseln darstellen, verfügen bereits über mehr Systemwissen, so dass sie eigenständig an einer größeren Menge an Quelldateien arbeiten können. Andere Entwickler arbeiten hauptsächlich mit dem Koordinator bei der Feature-Entwicklung zusammen.

Man könnte also durchaus den positiven Schluss ziehen, dass im Projektteam diverse Entwickler entweder aufgebaut werden und/oder bereits über fortgeschrittenes Systemwissen verfügen. Es wäre sogar möglich, dass selbst das eigenständige Wissen in den Knowledge Islands des Koordinators und der besagten vier weiteren Entwickler durch das gemeinsame Wissen in den Knowledge Balances und dem einhergehenden Knowledge Sharing ausgeglichen wird.

Die DETANGLE-Analyse der Android-App kommt zu sehr ähnlichen Ergebnissen wie bei der iOS-App und wird deshalb an dieser Stelle nicht weiter erläutert.

6. Kennzahlen zur Auswertung der Effektivität in der Wissensverteilung

Für die weitere Analyse werden die eher qualitativen visuellen Eindrücke der Netzwerkdiagramme ergänzt durch die quantitative Auswertungen der Daten. Es werden dafür zwei, den jeweiligen Mustern entsprechende Indices, der Knowledge-Island-LOC-Index und den Knowledge-Balance-LOC-Index gemessen.

Knowledge-Island-LOC Index (KIL)

Das ist der prozentuale Anteil der Lines of Code (LOC) der Quellcode-Dateien, an denen genau ein:e Entwickler:in gearbeitet hat, im Vergleich zu den LOC aller Quellcode-Dateien, an denen in einem bestimmten Zeitraum generell entwickelt wurde. Die Zahl wird pro Gesamtsystem oder pro Verzeichnis gemessen.

Knowledge-Balance-LOC Index (KBL)

Das ist der prozentuale Anteil des LOC der Quellcode-Dateien, an denen genau zwei Entwickler:innen gearbeitet haben, im Vergleich zu den LOC aller Quellcode-Dateien, an denen in einem bestimmten Zeitraum generell entwickelt wurde. Dabei können pro Quellcode-Datei aus dem gleichen Verzeichnis auch unterschiedliche Paare an Entwickler:innen gearbeitet haben.

Die beiden Knowledge-Island-LOC (KIL) und Knowledge-Balance-LOC (KBL) Index-Werte ergeben zusammen einen Wert unter 1.0 (d. h. unter 100 Prozent). Das Delta zu 1.0 (100 Prozent) ergibt den LOC-Anteil an Dateien in einem Verzeichnis, an denen mindestens drei Entwickler:innen aktiv beteiligt waren. Die KIL- und KBL-Werte für die gesamte iOS-App sind nun in Abb. 7 dargestellt.


Abb. 7: Veränderung der KIL- und KBL-Werte der iOS-App von Q2 bis Q4/2020.

Daraus lassen sich die obigen Schlüsse quantitativ bestätigen:

  1. Der Knowledge-Island-LOC-Index beträgt 27 Prozent (ca. ¼) in Q4/2020 für die gesamte iOS-App. Dabei ist der KIL-Wert in Q4 sogar um 32 Prozent gefallen (im Vergleich zu Q3/2020), was zunächst einen guten Trend widergibt und zeigt, dass die Wissensinseln hinter der/m Hauptentwickler:in abnehmen.
  2. Dagegen ist der Knowledge-Balance-LOC-Index der iOS-App über das ganze Jahr 2020 auch nach dem Teamwechsel knapp über oder gleich dem kritischen Schwellenwert von 20 Prozent (ca. ⅕) geblieben. Das bedeutet, dass die in den Netzwerk-Diagrammen sichtbare Zusammenarbeit als Zweier-Teams bei weitem noch nicht ausreicht, um zumindest einen mittleren Wert von 30 Prozent oder einen guten Wert von 40 Prozent der Codebasis an Knowledge Balances für ein gutes Knowledge Sharing zu erreichen.

Im  Vergleich dazu betrachten wir nun die Werte für die Android-App in Abb. 8:

  1. Hier ist der Knowledge-Balance-LOC-Index nach dem Teamwechsel sogar gefallen. Dieser liegt aber noch bei einem Wert von 28 Prozent. Das bedeutet, dass die Zusammenarbeit in Zweier-Teams bei Android etwas fortgeschrittener als bei iOS ist. Das deutet sich bereits beim direkten Vergleich der Netzwerk-Diagramme der iOS- und Android-Feature-Entwicklung an.
  2. Das bessere Bild bezüglich Knowledge Balances wird aber durch einen konstant kritischen Knowledge-Island-LOC-Index der Android-App aufgehoben. Dieser beläuft sich auf sehr hohe 57 Prozent in Q4/2020 und impliziert, dass der Koordinator bei der Android-Feature-Entwicklung weiterhin eine übergroße Wissensinsel darstellt.


Abb. 8: Veränderung der KIL- und KBL-Werte der Android-App von Q2 bis Q4/2020

7. Empfehlungen zur Verbesserung der Wissens- und Aufwandsverteilung

Selbst unter dem eingeschränkten Zugang zum SAP JIRA-Projekt und der fehlenden Möglichkeit, mit den Entwickler:innen zu kommunizieren, würden wir folgende Empfehlungen zur Verbesserung der Effektivität bei der Entwicklung neuer Features in der Corona-Warn-App aussprechen:


Tabelle 2: Empfehlungen zur Verbesserung der Wissens- und Aufwandsverteilung in der iOS- und in Android-Version der Corona-Warn-App

9. Collective Code Ownership Considered Harmful

Die KIL- und KBL-Werte mit Bezug zur Featureentwicklung lassen sich auch auf Quellcodeverzeichnisse herunterbrechen wie in Abb. 9 für Q4/2020 dargestellt. Auf der horizontalen Achse werden die KIL-Werte und auf der vertikalen Achse die KBL-Werte für Quellcode-Verzeichnisse aufgetragen. Jeder Kreis stellt ein Quellcode-Verzeichnis dar, wobei die Kreisfläche die LOC aller geänderten Quellcodedateien in dem Verzeichnis spiegelt. D. h. je größer der Kreis, desto mehr LOC machen die Quellcodedateien aus, die in dem Verzeichnis in dem betrachteten Zeitraum zur Featureentwicklung verändert wurden.


Abb. 9: Quellcode-Verzeichnisse und deren KIL- und KBL-Werte (iOS in Q4/2020)

Das Diagramm ist in folgende vier Quadranten mit jeweils unterschiedlicher Rahmenfarbe unterteilt:

Grün: Verzeichnisse, deren Knowledge-Island-Wert gering ist (unter 30 Prozent) und zusätzlich einen mittleren bis hohen Anteil (mindestens 30 Prozent) an Knowledge-Balance-Dateien aufweisen. Es handelt sich also dabei um eine sehr gute Wissensstruktur.

Gelb: Verzeichnisse, deren Knowledge-Island-Wert mittel bis hoch ist (über 30 Prozent), die aber durch einen mittleren bis hohen Anteil (mindestens 30 Prozent) an Knowledge Balances ausgeglichen werden. Diese Verzeichnisse weisen eine immer noch gute Wissensstruktur auf.

Rot (rechter Quadrant):Verzeichnisse, deren hoher Knowledge-Island-Wert nicht durch Knowledge Balances ausgeglichen wird. Hier haben wir es mit kritischen Knowledge Islands zu tun.

Dunkelrot (linker Quadrant):Verzeichnisse, an denen mindestens drei Entwickler:innen gearbeitet haben, die weder kritischen Knowledge Islands noch guten Knowledge Balances zugerechnet werden können. Diese Verzeichnisse bedürfen einer weiteren kritischen Überprüfung, wie viele Entwickler:innen tatsächlich daran gearbeitet haben, und ob es sich eher um eine “geordnete” oder “chaotische” Arbeitsweise der Entwickler:innen an gemeinsamen Quellcode-Dateien handelt.

Die Gründe, diese Verzeichnisse dennoch als dunkelrot, also als sehr kritisch anzusehen, werden mit der Betrachtung des Prinzips der “Collective Code Ownership” unten erörtert.

Diese Kategorisierung lässt sich exemplarisch an Extrembeispielen nachvollziehen. Eines davon sind die “grünen” Verzeichnisse oben links (KIL-Wert von 0, KBL-Wert von 1). Diese Kreise repräsentieren Verzeichnisse, in denen ausschließlich zu zweit entwickelt wurde. Im Gegensatz dazu stellen die Kreise rechts unten im Diagram (KIL-Wert von 1, KBL-Wert von 0) “rote”, kritische Knowledge-Island-Verzeichnisse mit einer/m einzelnen Entwickler:in dar.

Nun betrachten wir die Auswahl an Verzeichnissen, die wir bereits in unserem Blog in Bezug auf Architektur-Qualität, Dokumentation und technische Schulden als verbesserungsbedürftig ausgemacht haben [6] . Dabei handelt es sich um die Risk- und Exposure-Submission-Verzeichnisse des iOS-App-Quellcodes, die Features zur Risikobewertung und zur Handhabung von Covid-Test-Ergebnissen abdecken. Diese Verzeichnisse weisen eine globale Kopplung dieser Features auf und sollen auch aus Sicht der Wissensverteilung betrachtet werden.

Tabelle 3: KIL- und KBL-Werte der Risk- und Exposure-Submission-Verzeichnisse und LOC der geänderten Quellcodedateien in Q4/2020

Die Betrachtung derer Knowledge-Index-Werte lässt mehrere Schlussfolgerungen zu:

  • Das Verzeichnis
    src/xcode/ENA/ENA/Source/Scenes/Exposure Submission/__tests__ aus dem grünen Quadranten repräsentiert eine sehr gute Wissensstruktur mit guten Knowledge-Balance– und geringen Knowledge-Island-Anteilen.
  • Im Verzeichnis
    src/xcode/ENA/ENA/Source/Services/Risk/Calculation aus dem gelben Quadranten wird die Eigenschaft als Knowledge Island durch einen hohen Knowledge-Balance-LOC-Wert ausgeglichen.
  • Die große Mehrzahl dieser Verzeichnisse liegt im dunkelroten Quadranten aus Abb. 9. Wir haben es hier weder mit Knowledge Islands noch Knowledge Balances zu tun. Das heißt, dass mehr als drei Entwickler:innen am Großteil der bearbeiteten Dateien beteiligt waren.

Für diese Verzeichnisse lässt sich messen, ob mehrere bis viele Entwickler:innen darin auf chaotische Art und Weise “zusammen” gearbeitet haben. Denn aus unseren Projekterfahrungen wissen wir, warum solche Quellcodeverzeichnisse kommende Wartungsaufwände “magisch” anziehen. Das sind Quellcodedateien, an denen viele Entwickler:innen immer wieder mal mehr oder mal weniger Änderungen durchführen mussten. Letztendlich tritt das “Diffusion of Responsibility”-Phänomen [7] ein, dass sich irgendwann dafür keiner mehr so richtig verantwortlich fühlt und Entwickler:innen teilweise den Durchblick verlieren, weil viele der Mit-Entwickler:innen den Code mitverändert haben.

Mittels der DETANGLE Analyse Methoden lässt sich zusätzlich der Committer-Friction-Index (CFI) dafür messen. Wir haben das Diagramm mit den Committer-Friction-Werten und der Anzahl an Entwicklern für Q4/2020 in Abb. 10 aufgetragen:


Abb. 10: CFI-Werte der Risk- und Exposure-Submission-Verzeichnisse; x-Achse: CFI, y-Achse: Anzahl Entwickler:innen

Die Betrachtung der Werte in Abb. 10 lässt folgende Beobachtungen zu:

  • Am Verzeichnis
    src/xcode/ENA/ENA/Source/Scenes/ExposureSubmission/__tests__  haben mit die höchste Zahl an 11 Entwickler:innen gearbeitet.Obwohl es einen hohen Knowledge-Balance-Index aufweist, liegt dessen Committer-Friction-Index dennoch im mittleren Bereich. D. h. ein Verzeichnis mit einer hohen Anzahl an Entwickler:innen kann gleichzeitig einen hohen Anteil an Quellcodedateien als Teil von Knowledge-Balances und andererseits mehrere Quelldateien aufweisen, die unstrukturiert von vielen Entwickler:innen bearbeitet wurden.
  • Folgende bisher erwähnten Verzeichnisse weisen hohe Committer-Friction-Index-Werte auf:
    • src/xcode/ENA/ENA/Source/Services/Risk/Provider
    • src/xcode/ENA/ENA/Source/Scenes/ExposureSubmission/View
    • src/xcode/ENA/ENA/Source/Services/Exposure Submission

An diesen Verzeichnissen mit einem hohen Committer-Friction-Index lässt sich der Effekt beobachten, dass sie zu Hotspots der Wartung mit hohen Bugfixing-Aufwänden werden.

Diese Quellcode-Bereiche lassen sich wie Knowledge Islands und Balances als Knowledge Tangles (wie in Tabelle 1 im ersten Teil des Artikels ausgeführt) visuell in den unteren Netzwerkdiagrammen sichtbar machen.

Abb. 11: KI/KBs der iOS-App Q4/2020, Risk und Exposure Submission Dateien umrandet

Abb. 12 zeigt zum einen Knowledge Islands/Balances der iOS-App in Q4/2020 in Verbindung mit Bugs als rote Dreiecke. Einige wenige Quelldateien sind von drei oder zwei Bugs betroffen, mehrere von einem Fehler, aber der überwiegende Teil (ca. 95 Prozent) ist fehlerfrei.


Abb. 12: Knowledge Tangles der iOS-App Q4/2020, Risk– und Exposure Submission-Dateien umrandet

Demgegenüber zeigt Abb. 12 für die iOS-App einen großen Knowledge Tangle auf, der im Vergleich zu Knowledge Islands und Balances sehr verstärkt von Fehlern betroffen ist. In beiden Diagrammen wurden Quelldateien aus den Risk– und Exposure Submission-Verzeichnissen schwarz umrandet, so dass erkennbar wird, dass diese, wie bereits durch die Werte aus Abb. 10 vermutet werden konnte, in großem Umfang in dem besagten Knowledge Tangle vertreten sind. Dabei stammen wiederum ca. 85 Prozent dieser Quellcodedateien aus den drei oben erwähnten und in Abb. 11 rechts angesiedelten Quellcodeverzeichnissen mit einem hohen Committer-Friction-Index.

Die Analyse und Visualisierung mit DETANGLE macht eindrucksvoll deutlich, dass Collective Code Ownership seine Tücken und in diesem Fall ausgeprägt negative Auswirkungen gezeigt hat.

9. Zusammenfassung und Empfehlungen

In vorliegenden Artikel haben die Autoren anhand einer Analyse der Entwicklung der Corona-Warn-App im Zeitraum von Q2 bis Q4 2020, Mittel und Wege vorgestellt, wie Teams und Projektverantwortliche den Zusammenhang zwischen Entwicklungsaufwänden und der Effektivität der Wissensverteilung messen und monitoren können. Mit den Befunden können Projekt- und Produktrisiken frühzeitig erkannt und entsprechende Gegenmaßnahmen zeitnah eingeleitet werden.

Im Einzelnen konnte durch die Analyse der Codehistorie festgestellt werden, dass Wissens- und Teamstrukturen nicht oder kaum explizit analysiert worden sein können. Die außerordentlich inhomogene Wissenverteilung (Knowledge Islands) in den Teams der beiden Teilprojekte iOS-App und Android-App wurde mit der Software Analyse Suite DETANGLE nachgewiesen und visualisiert. Man scheint sich auf das Prinzip der Selbstorganisation von Teams mit seinen Reviews und gegenseitigen Feedbacks verlassen zu haben. Dass das nicht die erhoffte Wirkung hatte, zeigt die ebenfalls sehr inhomogene Verteilung der Entwicklungslast innerhalb der beiden Teams.

Bei der Android-App wurden 60 Prozent dieser Last von nur einer/m Entwickler:in verantwortet.

Bei der iOS-App 50 Prozent von zwei Entwickler:innen und das bei einer Teamgröße von bis zu 28 Entwickler:innen. Eine solche ineffektive Wissens- und inhomogene Aufwandsverteilung führt zu generellen Ineffizienzen im Entwicklungsprozess und zusätzlich auch noch zu unerwünschten Abhängigkeiten von einzelnen Entwickler:innen. Ein Ausfall einer/s dieser Entwickler:innen kann die Qualität, den Launchtermin oder den gesamten Projekterfolg nachhaltig gefährden.

Neben dem leicht erfassbaren Muster der Knowledge Islands, wurden als weitere Muster die Knowledge Balances und Knowledge Coordinators eingeführt, die per Netzwerkdiagramme visualisiert und bis auf Ebene der Quellcodeverzeichnisse quantifiziert werden können. Dadurch weiß man, wo und wann Knowledge Islands und einzelne Koordinator:innen ein Risiko darstellen und wie sie mittels einer Verstärkung der Knowledge Balances ausgeglichen werden können.

Zu guter Letzt wurde gezeigt, dass das Prinzip des Collective Code Ownership sogar Schaden anrichtet und betroffene Bereiche des Codes sich zu Hotspots der Wartung entwickeln können.

Bugfixing ist stets Blindleistung. Um eine nachhaltige Wertschöpfung in der Featureentwicklung zu gewährleisten, empfehlen die Autoren die Durchführung dieser Analysen begleitend über die Iterationen der Entwicklung hinweg. Die Ergebnisse wären ein wesentlicher Input für Team-Reviews, um Verbesserungsmaßnahmen zu initiieren oder zum Zwecke der Transparenz für Projektverantwortliche, Auftraggeber und Nutzer.

Unsere Diagnose, dass die Wissensverteilung und die Verteilung der Entwicklungsaufwände in den Entwicklungsteams der Corona-Warn-App problematisch ist, könnte durch die Realität bestätigt worden sein, denn beim Launch neuer Features traten wiederholt Verzögerungen und funktionale Einschränkungen, bis hin zum Ausfall der App auf [8].

Anmerkung: Die vorgestellten Ergebnisse und Erkenntnisse sind nur ein kleiner Teil dessen, was an relevanten Informationen hätte erzielt werden können, falls die Autoren einen offenen Zugang zu den Entwicklerteams und zu den von dem Projektteams verwendeten, aber nicht-öffentlichen SAP JIRA-Projekten erhalten hätten.

10. Über den Ansatz

Die Analyse der Entwicklung der Corona-Warn-App wurde mit den durch die Open Source Entwicklung zugänglichen Daten auf GitHub, aber ohne die Mitwirkung der mit der Entwicklung beauftragten Unternehmen durchgeführt. Für die Analyse haben wir die DETANGLE Analyse Suite verwendet, die eine Auswertung der GitHub Issues/Pull Requests, der beteiligten Entwickler und die darauf zurückzuführenden Code-Änderungen über die gesamte Code-Historie der beiden Apps erlaubt. Die Daten aus dem nicht-öffentlichen SAP JIRA Issue Projekt konnten nicht herangezogen werden. Eine detaillierte Beschreibung des Vorgehens ist unter [3] zu finden.

Wir fokussieren uns dabei auf Daten, die sich aus den Änderungen an gemeinsamen Quellcode-Dateien für neue Features ergeben. Nicht berücksichtigt werden Merges der Commit-Historie, die auf Pull Requests zurückgehen, da diese meist in Zusammenhang mit Reviews stehen und die Daten hinsichtlich der Wissensverteilung “verwässern” würden.

Links

[1] Agile Alliance, Collective Code Ownership
https://www.agilealliance.org/glossary/collective-ownership

[2] heise developer, “Collective Code Ownership: Ein Anti-Pattern?”
https://www.heise.de/developer/artikel/Collective-Code-Ownership-Ein-Anti-Pattern-3909449.html

[3] Blog Cape of Good Code, Details zum Vorgehens bei der Analyse ("Zum Vorgehen")
https://capeofgoodcode.com/de/wissen/corona-warn-app-auf-dem-weg-zu-kritischen-technischen-schulden/

[4] JCON 2020, “Feature and Time-Based Software Analysis”,
Measuring Development Effort: https://youtu.be/aD4OQScGILo?t=790
5 Minuten: 13:10 – 18:27

[5] Blog Cape of Good Code, Kooperation und Knowledge Sharing für Agile Remote Entwicklung
https://capeofgoodcode.com/de/wissen/kooperation-und-knowledge-sharing-fuer-agile-remote-entwicklung/

[6] Blog Cape of Good Code, “Corona Warn App – Auf dem Weg zu kritischen Technischen Schulden?”
https://capeofgoodcode.com/de/wissen/corona-warn-app-auf-dem-weg-zu-kritischen-technischen-schulden/

[7] Diffusion of Responsibility
https://web.archive.org/web/20100227092905/http://greatergood.berkeley.edu/greatergood/archive/2006fallwinter/keltnermarsh.html

[8] Handelsblatt, “Die Fehler der Corona-App offenbaren eine gefährliche Schweigsamkeit der Firmen”
https://www.handelsblatt.com/meinung/kommentare/kommentar-die-fehler-der-corona-app-offenbaren-eine-gefaehrliche-schweigsamkeit-der-firmen/26038162.html