Burnout Syndrom - Warum es Software Entwickler trifft - Cape Of Good Code

Zusammenfassung

• Burnout-Symptome bei Software Entwicklern sind Zeichen einer ernsthaften und langwierigen Erkrankung als Folge suboptimaler Arbeitsprozesse und -bedingungen.
• Der Entwickler-Burnout ist weiter verbreitet als man denkt. Es trifft Unternehmen über Fluktuation, eine reduzierte Team-Produktivität und einen erhöhten Krankenstand genauso hart wie den betroffenen Mitarbeiter selbst.
• Die Gründe sind oftmals umfangreiche aber “sinnlose” Arbeiten, häufig wechselnde Prioritäten, unrealistische Ziele und Termine und Überbelastung.
• Frühindikatoren für diese wichtigsten Burnout-Ursachen lassen sich aus den Arbeiten am Code heraus mit der DETANGLE Analyse Suite identifizieren.
• Mit den Analyseergebnissen haben Projektleiter/das Management Informationen zur Hand, um frühzeitig eine gesundheitsgefährdende Arbeitssituation seiner Entwickler zu erkennen und Gegenmaßnahmen einzuleiten.
• Durch die regelmäßige Anwendung dieser Analysen, lassen sich die Eergebnisse zusätzlich noch um den Trend der relevanten Kennzahlen über die Zeit ergänzen. Das macht es zunehmend einfacher die Ursachen für einen sich anbahnenden Burnout einzugrenzen.

Warum sind Software Entwickler so oft vom Burnout Syndrom betroffen?

Das Burnout-Syndrom ist eine für die Betroffenen ernsthafte und langwierige Erkrankung.  Die Medizin tut sich mit einer eindeutigen Definition und Diagnose für Burnout  immer noch schwer.  Es wird bis heute regelmäßig mit Depressionen verwechselt.

Eine eingängige Beschreibung ist z.B. unter Burnout Prevention for Software Developers [1] zu finden.

“Burnout is one of those things you don’t realize until you already have it. But people with symptoms of burnout are people who are generally always working, always on — they feel they can never take a break or have any down time.”

— Abby Kearns, Cloud Foundry

Die Folgen eines Burnout sind für den einzelnen Entwickler, das Team und die Produktivität des Unternehmens gravierend. Folgende Auflistung einiger Symptome werden immer wieder genannt [2]:

• “Becoming cynical or overly critical at work”
• “Lack of energy and concentration with no evident cause”
• “Constant fatigue”
• “Procrastinating on tasks that you used to do enthusiastically”
• “Feelings of dread, apathy, and being out of control”
• “Lowered productivity”
• “Minor to major anxiety”

• “Outbursts of anger”

Nun könnte man entgegen, dass Burnout in jedem Berufszweig vorkommt. Aber das Softwareengineering ist dafür besonders prädestiniert. Und das hat seine Gründe.

‘Software engineering has no boundaries. Rather than a set amount of hours each day, work is driven by idealistic management deadlines. As one senior tech CEO told me, “I knew there was no chance of hitting my deadline, but I wanted to push the engineering team to work faster.” Under-resourcing is common because developer recruiting is hard — and expensive. ‘#

Über mehrere Artikel hinweg werden software-spezifische Gründe dargelegt. Burnout Prevention for Software Developers [1] führt folgende Ursachen auf:

1. “Unclear or rapidly shifting direction” (A),
2. “The bus factor is low” (B),
3. “Programming is isolating” (D),
4. “Draining work of maintenance” (C),
5. “Impatient or ungrateful users” (im Falle der Open-Source Entwicklung) und
6. “Coding for others”

Weitere Artikel How Not to Burnout: Guide for Software Developers [2], 7 Reasons why programmers burn out [3] und Only You Can Prevent Tech Burnout  [4] führen inhaltlich ähnliche und weitere Gründe auf, die aus eigener Erfahrung ebenso zutreffend sind.

Die diversen Themen, die die verschiedenen Autoren als ursächlich für einen Burnout benennen, lassen sich gut in vier Themenbereiche clustern:

Frühindikatoren für einen Burnout bei Software Entwicklern sind messbar

Der erste Schritt der Vorbeugung besteht darin, Indikatoren die den Burnout fördern, sichtbar zu machen. Für die Ursachencluster A, B und C aus dem vorigen Abschnitt erfassen wir mit unserer DETANGLE® Analyse Suite folgende Kenngrößen über die Zeit per Entwickler:

1. Wie hoch ist der Aufwand, mit dem ein Entwickler an der Wartung des Systems beteiligt ist und wie verhält sich dieser im Vergleich zur Feature-Entwicklung?
2. An wie vielen Features/User-Stories, arbeitet ein Entwickler gleichzeitig in einem Zeitraum, und was ist deren Aufwandsverteilung?
3. An wie vielen unterschiedlichen Quellcode-Verzeichnissen arbeitet der Entwickler gleichzeitig?
4. Mit wie vielen unterschiedlichen Programmiersprachen hat es der Entwickler zu tun?
5. Stellt ein Entwickler über längere Zeit durch relevantes Alleinwissen ein Risiko dar (und erhöht somit den Bus Factor, d.h. die Anzahl an Schlüsselentwicklern)?

Je höher der Aufwand des Einzelnen für Wartung, desto geringer ist der Anteil an wertschöpfenden und damit befriedigenden Tätigkeiten (C). Je höher die Anzahl der Features/User-Stories und je höher die Anzahl der Quellcode-Verzeichnisse oder Programmiersprachen, desto geringer ist der Fokus des Entwicklers (A), während der Bus Factor auch indirekt seine Arbeitslast widerspiegelt (B).

Bild 1: Bus Factor Trend über die Zeit

Das Bild zeigt den Bus Factor, d.h.  die Anzahl an Schlüsselentwicklern für das Django Open-Source Projekt. Es ist zu sehen, dass deren Anzahl von 2019 auf 2020 von 4 auf 7 Entwickler gestiegen ist und ca. 12% der Entwickler als Mission-critical gelten und auf den Bus Factor einzahlen. Der Ausfall eines dieser Entwickler stellt stets ein Projektrisiko dar. Da diese Schlüsselentwickler auch meist die höchste Arbeitslast und Verantwortung haben, sind diese besonders gefährdet für einen Burnout.

Damit ist der Bus Factor auch ein Frühindikator für die Anzahl der Burnout gefährdeten Mitarbeiter. Wird ein Entwickler über längere Zeit als  Bus Factor erfasst, sollte das Management versuchen in Abstimmung mit dem Entwickler die Last und die hohe Verantwortung wieder zu reduzieren.

Das Ursachen der Kategorie D aus dem vorigen Abschnitt (Problem einer mangelhaften Kooperation) haben wir in mehreren Blogs bereits angesprochen. Unter Software Due Diligence – Entwickler und ihre Zusammenarbeit im Fokus [5] und Collective) Code Ownership neugedacht [6] haben wir dargelegt, dass es nicht auf die Star-Solisten, sondern auf die Team-Stars ankommt, um den Stresslevel im Team zu begrenzen und dabei trotzdem Produktivität und Qualität zu verbessern.

Fazit

Softwareunternehmen sind “People” Unternehmen. Die intellektuell meist anspruchsvolle Entwicklungsarbeit wird durch Menschen und nicht von Maschinen geleistet. Das Risiko eines Burnouts ist angesichts der Herausforderungen bei der Software-Entwicklung real und gegenwärtig. Wir empfehlen dringend, das Risiko, dass Mitarbeiter durch Überlastung oder Unzufriedenheit ausfallen über die Ermittlung von Burnout-Indikatoren transparent zu machen. Damit besteht die Möglichkeit zeitnah entgegenzusteuern. Es trifft oft die produktivsten Mitarbeiter und das in einem Arbeitsmarkt, in dem es schwierig ist, gleichwertigen Ersatz zu finden.

Cape of Good Code hat einen analytischen, softwaregestützten Ansatz entwickelt, um das Burnout-Risiko  nachvollziehbar zu identifizieren. Bei regelmäßigen Einsatz von DETANGLE kennt das Management genau den Stresspegel der Entwickler und kann die Führungskräfte auffordern, diesen zu verringern und die Arbeitslast besser zu verteilen. Die bereits stark gefährdeten Mitarbeitern kann man durch Coaching unterstützen, um mit der persönlichen Belastung besser umgehen zu können.

Frequently Asked Questions

Welche Voraussetzungen müssen erfüllt sein, damit eine Software automatisiert durch die Software Analyse Suite untersucht werden kann.

Bei der Entwicklung der Software sollte ein sogenanntes Code-Repository verwendet worden sein, in dem einzelne Schritte in der Entwicklung des Source-Codes durch die Entwicklermannschaft gespeichert werden. Git als Code-Repository wird mittlerweile in hohem Umfang dafür eingesetzt. Zudem werden Informationen aus dem Bug-/Issue-Tracker und dessen Verbindungen zum Code-Repository verwendet und ausgewertet. Falls nach gängigen Mustern in der Anwendung dieser Tools vorgegangen wird, ist eine sofortige Konfiguration und Durchführung der Analyse möglich.

In anderen Fällen ist ein “Vor-Projekt” zur tieferen Analyse der uneinheitlichen, nicht-standardgemäßen Vorgehensweise  und zur Bereinigung der Daten nötig, um die Analysen durchzuführen. Ergebnis eines solchen Vor-Projekts sind konkrete technische Prozess-Verbesserungsvorschläge zur effizienten Verwendung dieser Tools im Sinne eines standardisierten Vorgehens und dem Aufbau eines Projekt-Gedächtnisses zum Nutzen aller Stakeholder wie Projektleiter/-manager, Product Owner und Entwicklern.

Können die Analysen remote durchgeführt werden?

Das ist kein Problem. Die IT des betreffenden Unternehmens sollte eine VPN Verbindung zur Verfügung stellen, über die unsere DETANGLE® Analyse Software auf einem betreffenden Rechner (oder Virtuellen Maschine) des Unternehmens aufgespielt werden kann. Der zu untersuchende Code verbleibt zu jeder Zeit ausschließlich in der Infrastruktur des Unternehmens. Eventuelle Interviews können über Online-Meetings oder vor Ort durchgeführt werden.

Kann eine Software zu umfangreich für eine automatisierte Untersuchung mit DETANGLE sein?

Ein paar Millionen Code-Zeilen stellen kein Problem dar, um sie in einem Durchgang zu untersuchen. Bei >10 Millionen Codezeilen müsste geprüft werden, ob sich der Code in sinnvolle Untersuchungscluster unterteilen lässt. Das kommt insbesondere der zutreffenden Interpretation der Analyseergebnisse zugute.

Links

[0] Photo by Nataliya Vaitkevich from Pexels

[1] Burnout Prevention for Software Developers

[2] How Not to Burnout: Guide for Software Developers

[3] 7 Reasons why programmers burn out | by Rhea Moutafis

[4] Only You Can Prevent Tech Burnout | by April Wensel

[5] Software Due Diligence – Entwickler und ihre Zusammenarbeit im Fokus

[6] (Collective) Code Ownership neugedacht – Über Risiken der Wissensverteilung am Beispiel der Corona-Warn-App