Code Ownership neugedacht – Teil 2
Dies ist der zweite Teil des Artikels "(Collective) Code Ownership neugedacht – Über Risiken der Wissensverteilung am Beispiel der Corona-Warn-App".
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.
Tabelle 2: Definition der Knowledge-Island-LOC and Knowledge-Balance-LOC Indices
| Knowledge Index | Beschreibung |
|---|---|
| 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. Daraus lassen sich die obigen Schlüsse quantitativ bestätigen:
- 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.
- 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:
- 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.
- 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.
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 3: Empfehlungen zur Verbesserung der Wissens- und Aufwandsverteilung in der iOS- und in Android-Version der Corona-Warn-App
| iOS App | Android App | |
|---|---|---|
| Balance | Bestehendes Knowledge Sharing weiter ausbauen, da der Stand der aktuellen Knowledge Balances knapp am unteren kritischen Schwellenwert der Codebasis liegt.Fast alle Knowledge Balances (bis auf eine oder zwei, siehe Abb. 6) um die/den Koordinator:in können noch ausgebaut werden.Teilweise dürfen bis auf die/den Koordinator:in, die an den Knowledge Balances beteiligten Entwickler:innen ihr eigenständiges Wissen noch erweitern, da der gesamte Knowledge-Island-LOC Wert noch keine 30 Prozent überschreitet. Nur bei einem größeren Knowledge Island um eine:n weitere:n Entwickler:in ist Vorsicht geboten. | Den hohen kritischen Knowledge Island LOC Wert gilt es abzubauen. Die um die drei weiteren Entwickler:innen entstandenen Wissensinseln dürfen nicht weiter zunehmen. Stattdessen soll weiteres Wissen von/vom Koordinator:in zu anderen Entwickler:innen übertragen werden, so dass deren Knowledge Balance Beteiligung und Wissensstand ausgebaut werden. |
| Coordinator | Eine:n zweite:n Koordinator:in aufbauen, um das Risiko des potentiellen Ausfalls (besonders im Falle einer/s externen Mitarbeiter:in) zu minimieren. Die kleinen, im Entstehen begriffenen Knowledge Balances ohne die/den Koordinator:in verstärken (s. blaue Rechtecke in Abb. 6 ) und eine:n dieser Entwickler:innen als zweite:n Koordinator:in in Betracht ziehen. | Wie für iOS ausgeführt (auch bei der Android-App gibt es zwei kleine im Entstehen begriffene Knowledge Balances ohne Beteiligung der/s Koordinator:in) |
| Tangle | Die Arbeit in den qualitativ und wissens-kritischen Risk und Exposure Submission Verzeichnissen besser separieren bzw. die Architektur bezüglich deren Qualität verbessern. | Keine valide Aussage möglich. |
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.
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 [1]. 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.
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 [2] 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:
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. 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.
Demgegenüber zeigt Abb. 13 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.
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 [3].
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.
- Cape of Good Code, Blog: Corona-Warn-App – Auf dem Weg zu kritischen Technischen Schulden?
- Wikipedia: Verantwortungsdiffusion
- Handelsblatt: Die Fehler der Corona-App offenbaren eine gefährliche Schweigsamkeit der Firmen
