Fallstrick Qualität beim Stack Ranking im Software Engineering

“If you’re just using your engineers to code, you’re only getting about half their value” 

        Marty Cagan (Founder, Partner SVPG)

Entwickler sind keine “Feature Factory” Arbeiter

Im ersten Blog Fallstricke des Stack Rankings von Software Entwicklern bin ich darauf eingegangen, dass man beim Stack Ranking für Software Entwickler sehr leicht falsche Akzente setzen kann. Da Softwareentwicklung eher einem Teamsport gleicht, müssen beide Aspekte, die eigenständigen/alleinigen Code-Beiträge eines Entwicklers in Beziehung zu den gemeinsamen Arbeiten am Code in Zweierteams in Relation gesetzt werden. Denn nur das zweite führt zum Wissensaustausch, dem Team-Alignment und der Team-Resilienz bei.

Es gibt noch einen weiteren Aspekt, der bedacht werden muss. Im oben erwähnten Blog haben wir gesehen, wie man die Aufwände eines Entwicklers mit in einen “Effort on Knowledge Islands %” und einen “Effort on Knowledge Balances %” (und einem verbleibenden Aufwand mit hoher “Contributor Friction”) aufteilen kann. Im Blog Positiver Impact von Entwicklerbeiträgen [1] zu Knowledge Balances haben wir gesehen, dass der Code hinter Knowledge Balances oftmals nur in geringem Umfang von Bugs betroffen ist. Das liegt in der Natur der Sache bei der Arbeit von Zweierteams, deren Mitglieder sich ja ständig gegenseitig austauschen und die gegenseitige Arbeit “reviewen”.

Aber wie sieht es mit der Software-Qualität des Codes hinter Knowledge Islands aus, die hinter größerer Solo-Arbeit von Entwicklern liegen? Ganz offensichtlich kann ein/e Entwickler/in viele Features “quick and dirty” auf Biegen und Brechen implementieren, woraus sich aber später Bugs ergeben, die nicht unbedingt ihm alleine zugeordnet werden würden.

• Wie umfangreich ist dafür der Test-Code, die Test-Coverage oder andere Testwerte
• Werden von Code-Qualitätstools Findings gefunden, deren Behebung dringend empfohlen wird (wie z.B. versteckte Bugs)
• Wie ist die Design-  bzw. Architekturqualität in diesen Code-Bereichen? Ist dieser Code wartbar/verständlich und erweiterbar mit neuen Features?

Wieder nehmen wir, wie im vorherigen Blog, in der unteren Tabelle Bezug auf die Entwickler des Django Open Source Web Frameworks im Jahr 2023.  Die erste Spalte (“Feat. Effort”) erfasst den Aufwand, den der jeweilige Entwickler an der Entwicklung weiterer Features beigetragen hat. Die Kriterien “Effort Knowledge Islands %” und “Effort Knowledge Balances %”, die wir bereits im ersten Blog besprochen haben, erfassen die Aufwandsverteilung des jeweiligen Entwicklers in Solo- und Zweierteam-Arbeit.

Als weitere (zweite Spalte) kommt die Messgröße “Effort (FDI Code) %” vor. Sie steht für den Aufwandsanteil, der zu Code (bzw.  Quellcode-Dateien) mit hohem “Feature Debt Index” (FDI) geführt hat. “Feature Debt” erfasst unter anderem die Architektur-Kopplung im Code zwischen Features, die per Issue Tracker erfasst wurden. (Genauere Angaben zur Messung der “FDI” und der “Feature Effort” Metriken sind hier zu finden.) 

Tabelle: “Top Performer” Kriterium - “Effort (FDI Code) %” misst die Architektur-Qualität

Gemäß den Kriterien aus dem ersten Blog hätten wir Mariusz Felisiak als “Top Performer” eingestuft, obwohl er einen zu hohen “Effort Knowledge Islands %” von 76%  aufweist. Wenn wir auf den weiteren Aspekt der Softwarequalität Bezug nehmen, so sehen wir, dass sein Aufwand nur zu 7% Quelldateien mit hohem “Feature Debt” Indexwert geführt hat. Dies ist ein guter Indikator, dass auch die Design-Qualität seiner alleinigen Arbeit keine Mängel aufweist.

Des Weiteren haben wir Nick Pope, Ben Lomax und Francesco Panico (vierter, fünfter und achter Eintrag) als “Achiever” im ersten Blog zum Thema Stack Ranking eingestuft. Deren “Effort (FDI Code) %” Werte liegen bei bei akzeptablen 17% (unter 20%) bzw. 0%. Das gleiche trifft auf Jon Janzen zu, den wir bisher auch als “Top Performer” eingestuft haben, womit sich trotz dieses neuen Aspekts die bisherige Bewertung dieser Entwickler unverändert positiv bleibt.

Ins Auge stechen Ian Foote und Jeremy Nauta (zweiter und siebter Eintrag) mit sehr hohen “Effort (FDI Code) %” von 75% und 40%. Deren “Effort Knowledge Islands %” Anteile von 32% und 47% sind wohl in Ordnung, sie weisen aber extrem niedrige “Effort Knowledge Balances %” Anteile von 9% und 1% auf, so dass der von KIs und KBs unabhängige Aufwandsanteil der beiden bei jeweils 59% und 52% liegt. Dieser verbleibende Aufwand betrifft wohl Codebereiche, an denen mindestens drei Entwickler im gleichen Zeitraum gearbeitet haben. 

Im Blog Collective Code Ownership neu gedacht (Abschnitt “Collective Code Ownership Considered Harmful”) [2] haben wir an einem Beispiel aufgezeigt, dass genau diese Codebereiche vermehrt von Bugs und Wartung betroffen sind. Daher ist der hohe  “Effort (FDI Code) %” nicht diesen beiden Entwicklern zuzuschreiben. Im Gegenteil, die Arbeit an diesem Code dürfte sich kognitiv eher schwierig gestaltet haben, da Beiträge von mehreren Entwicklern zu beachten waren, die nicht “beschädigt” werden durften. 

Diese Codebereiche bedürfen allgemein eines architekturellen Refactoring oder einer Neustrukturierung, die im Team besprochen werden sollten, und sollten nicht negativ in die Bewertung einzelner Entwickler eingehen. Wie man generell mit einer hohen Anzahl solcher Codebereiche umgeht, und wie der Umgang mit Verbesserungen des Codes in eine Bewertung der Entwickler mit einfließen könnte, wäre ein weiterer Blog wert.

Im folgenden sei ein anonymisiertes Beispiel skizziert, das zeigt, wie ein sehr hoher  “Effort Knowledge Islands %” Anteil auch stark in die Irre führen kann. In der unteren Abbildung sehen wir ein Codebeispiel mit sehr hoher Feature-Kopplung zwischen den Quelldateien. Die Rechtecke stellen Quelldateien dar, die blauen Kreise bilden Feature-Tickets aus dem Issue Tracker und eine Verbindung zwischen Quelldatei und Feature bedeutet, dass die Quelldatei für die Umsetzung des Features verändert wurde. 

Sichtbar werden drei größerer Cluster mit einer hohen Feature-Kopplung: links oben, rechts oben und unten in der Mitte. In jedem Cluster werden viele Dateien auf chaotische Art und Weise von vielen Features gleichzeitig verändert. Die Wahrscheinlichkeit von unbeabsichtigten Seiteneffekten (wie das Brechen vorhandener Funktionalität, der Einführung von Bugs) bei der weiteren Bearbeitung dieser Dateien ist sehr hoch. Insgesamt ist die architekturelle Qualität dieser Codebereiche verbesserungsbedürftig und ein “Detangling” hier sehr angebracht. 

Abbildung 1: Drei Code-Cluster mit hoher Feature-Kopplung

Abbildung 2 unten blendet zusätzlich die Entwickler (kleine Dreiecke) mit ein, die an diesen Dateien gearbeitet haben. Die grünen Verbindungen markieren die Quellcode-Dateien, die der rot markierte Entwickler bearbeitet hat.

Abbildung 2: Code-Cluster mit hoher Feature-Kopplung und einem Entwickler

Wir können nun feststellen, dass diese drei Cluster auf ein und denselben Entwickler zurückzuführen sind. Dieser Entwickler ist extrem produktiv, hat einen sehr großen Anteil an der Entwicklung und hat viele Features umgesetzt. Aber die architekturelle Qualität des Codes wird mit ziemlicher Sicherheit zu erhöhten Aufwänden in der weiteren Entwicklung und zu Bugs führen.

[0] Photo by Pixels (JAVIER PIVAS FLOS)

[1]  Positive Impact of Developer Contributions

[2]  Rethinking Collective Code Ownership (section "Collective Code Ownership Considered Harmful")