Umso erstaunter war ich, als mir kürzlich in einem ruhigen Moment auffiel, dass ich mich selbst im Arbeitsalltag erstaunlich selten daran halte. Und schlimmer noch: dass ich ziemlich gut darin geworden bin, mir das auch noch schönzureden.

Eisenhower ist aus meiner Sicht weiterhin ein sinnvolles Werkzeug – das ist mir wichtig vorwegzuschicken. Gleichzeitig stößt dieses Zeitmanagement-Modell aus der Mitte des 20. Jahrhunderts – entwickelt von einem US-General und späteren Präsidenten – im Arbeitsalltag moderner Wissensarbeiter erstaunlich schnell an seine Grenzen.

Dafür gibt es mehrere Gründe.

Kognitive Überlastung: Wenn zu viele Reize um Aufmerksamkeit konkurrieren

Wissensarbeiter – egal ob Fachspezialisten, Berater oder Entscheider – leiden heute weniger an fehlender Priorisierung als an kognitiver Überlastung. Die ständige Notwendigkeit, zwischen konzentrierter Arbeit an komplexen Fragestellungen und reaktiver Kommunikation zu wechseln, erzeugt Kontextwechselkosten (siehe auch [1]), die Fokus, Entscheidungsqualität und letztlich auch die eigene Zufriedenheit spürbar beeinträchtigen.

Die Eisenhower-Matrix verspricht an dieser Stelle eigentlich Orientierung, scheitert jedoch häufig an der psychologischen Realität der Illusion of Urgency [2]: Aufgaben fühlen sich dringend an, erzeugen Handlungsdruck und verlangen Aufmerksamkeit – ohne deshalb, um in der Sprache von Eisenhower zu bleiben, automatisch auch wichtig oder tatsächlich dringend zu sein.

Für mich hat sich daraus eine einfache, bewusst pragmatische Regel ergeben: Aufgaben, die sich in weniger als fünf Minuten erledigen lassen, versuche ich unmittelbar abzuschließen. Nicht aus Effizienzgründen im klassischen Sinne, sondern um kognitive Last zu reduzieren. Jede nicht beantwortete Rückfrage, jede angefangene, aber nicht abgeschlossene Kleinigkeit bleibt im Kopf präsent – und konkurriert dort mit eigentlich wichtigeren Themen um Aufmerksamkeit.

Das Problem: In meinem hochfragmentierten Arbeitsalltag gibt es überraschend viele „kurze Anfragen“. Und so schlägt die Fünf-Minuten-Regel bei mir erstaunlich oft Eisenhower.

Und ja, ich weiß: Man muss Mails und Chatnachrichten nicht sofort lesen. In der Theorie leuchtet mir das vollkommen ein. In der Praxis stressen mich 13 ungelesene Teams-Nachrichten jedoch zuverlässig. Disziplinierte Zeitfenster für Mail- und Chatkommunikation funktionieren für manche hervorragend. Für mich nicht. Und so stößt auch Eisenhower an seine Grenzen.

Kognitive Last der Organisation: Wenn zu viele Themen gleichzeitig offen sind

Nun ist kognitive (Über-)Last kein individuelles Versagen. Sie ist in vielen Fällen ein übergreifendes organisatorisches Problem. Organisationen arbeiten selten an einem Thema zur gleichen Zeit. Sie arbeiten an sehr vielen. Projekte, Initiativen, Abstimmungen, Eskalationen, strategische Themen und operative Kleinigkeiten laufen parallel – oft über Monate oder sogar Jahre. Jeder offene Vorgang erzeugt kognitive Last. Nicht nur bei Einzelpersonen, sondern im System insgesamt: in Meetings, Statusrunden, Entscheidungsprozessen oder auch nur, weil ich diese eine nervige Aufgabe nun schon zum dritten Mal in die Folgewoche verschiebe.

Diese systemische kognitive Last entsteht unabhängig davon, wie dringend oder wichtig ein einzelnes Thema gerade ist. Allein die Tatsache, dass etwas „noch offen“ ist, bindet Aufmerksamkeit. Ein psychologisches Fundament dieser Beobachtung liefert übrigens der Zeigarnik-Effekt, der besagt, dass uns unterbrochene, unerledigte Aufgaben kognitiv stärker beschäftigen als abgeschlossene [4]. Das kostet Energie – selbst dann, wenn faktisch gerade niemand daran arbeitet.

Ein besonders plastisches Beispiel dafür habe ich im behördlichen Umfeld erlebt. Eine Broschüre sollte aktualisiert werden – kein besonders dringendes Thema, von mittlerer Wichtigkeit. Der erste Entwurf war schnell erstellt. Danach passierte lange Zeit: nichts. Aufgrund interner Prozesse mussten verschiedene Einheiten involviert werden, zwischen den einzelnen Abstimmungen lagen jeweils mehrere Wochen.

Das Ergebnis? Ein Prozess über 20 Monate. Durch unzählige Abstimmungsrunden und Liegezeiten musste sich jeder Beteiligte in jedem Termin neu eindenken („Wo standen wir nochmal?“). Am Ende wurde konservativ geschätzt mindestens das Zehnfache der eigentlichen Arbeitszeit investiert, nur weil das Thema immer wieder liegen blieb. Ein klassisches Beispiel dafür, wie „nicht dringende“ Themen durch reinen Zeitverzug zu hocheffizienten Ressourcenfressern mutieren.

Die Eisenhower-Matrix betrachtet Aufgaben isoliert. Sie hilft dabei, einzelne To-dos zu priorisieren. Was sie jedoch systematisch ausblendet, ist die kumulative Wirkung vieler paralleler, offener Themen auf eine Organisation.

In der Praxis ist es oft nicht das einzelne wichtige oder dringende Thema, das überlastet – sondern die schiere Anzahl an offenen Baustellen. Aus einer Lean-Perspektive ist es deshalb sinnvoll, die Anzahl gleichzeitig offener Themen möglichst gering zu halten. Nicht nur, um schneller zu werden, sondern um arbeitsfähig zu bleiben.

Genau hier beginnt ein Aspekt, den Eisenhower nur unzureichend adressiert: Offene Themen sind nicht neutral. Sie sind nicht einfach „noch nicht dran“. Sie erzeugen Kosten – allein durch ihr Liegenlassen.

Cost of Delay: Wenn Liegenlassen teuer wird

Wenn man genau hinschaut, habe ich im obigen Behördenbeispiel bereits ein Konzept verwendet, ohne es zu benennen: Cost of Delay.

Nicht die (gefühlte und meist sehr subjektive) Wichtigkeit einer Aufgabe entscheidet über ihre Priorität, sondern die Kosten, die entstehen, wenn sie nicht umgesetzt wird. Diese Kosten sind oft nicht sichtbar – aber sie sind real.

Ein einfaches Beispiel: Ein kurzes Debriefing zu einem Konferenzbesuch an Kollegen zu schicken, ist selten dringend und meist auch nicht besonders wichtig. Während der Zugfahrt nach Hause ist das in wenigen Minuten erledigt. Zwei Wochen später brauche ich dafür schon deutlich länger. Zwei Monate später muss ich anhand meiner Notizen rekonstruieren, was ich eigentlich mitteilen wollte.

Die Aufgabe ist dieselbe geblieben – der Aufwand nicht. Die Verzögerung hat hier keinen inhaltlichen Mehrwert erzeugt, sondern ausschließlich zusätzliche Arbeit. Genau das beschreibt Cost of Delay.

In Organisationen wirkt dieser Effekt noch stärker. Der eigentliche Cost of Delay entsteht häufig nicht durch fehlende Umsetzung, sondern durch das Wiederanlaufen: sich erneut einlesen, Kontexte rekonstruieren, Entscheidungen erklären, Abhängigkeiten neu klären. Je länger ein Thema liegt, desto höher werden diese Reibungsverluste. Besonders schön wird es dann, wenn Nachfragen nach dem Stand einer Aufgabe und ein oder zwei Feedbackschleifen in Summe bereits mehr Zeit kosten als die eigentliche Erledigung.

Eisenhower hilft dabei zu entscheiden, was wichtig und dringend ist. Cost of Delay macht sichtbar, was es kostet, nichts zu entscheiden – und Themen immer wieder liegen zu lassen.

Mir ist bewusst, dass Cost of Delay ein abstrakter Begriff bleibt. Mir hilft dieser Perspektivwechsel jedoch sehr, meine Arbeitsprioritäten besser zu setzen. Übliche Dimensionen, die meinen höchst persönlichen Cost of Delay ausmachen, sind:

• der erwartete Mehrwert des Arbeitspakets (strategisch, operativ oder risikoseitig)
• Effizienz- und Reibungsverluste über die Zeit (Wiederanlauf, Abstimmung, Kontextverlust)
• die Möglichkeit, Themen sauber abzuschließen und damit kognitive Last zu reduzieren
• Lernen und Wissensgewinn – oder dessen Verzögerung

Ob ich eine Aufgabe selbst erledige oder delegiere, beantwortet Cost of Delay allerdings nicht. Aber dazu kommen wir im kommenden Abschnitt.

Verteilte Verantwortung: Wenn klassische Delegation an Grenzen stößt

Die Eisenhower-Matrix ist in einer Welt klarer Hierarchien entstanden. Aufgaben werden priorisiert, erledigt oder delegiert. Delegation setzt dabei etwas voraus, das lange selbstverständlich war: eine eindeutige hierarchische Ordnung mit klarer Weisungsbefugnis.

In der Sprache von Reinventing Organizations [5] würde man sagen: Eisenhower passt hervorragend zu bernsteinfarbenen, stark hierarchischen Organisationen. Führung bedeutet dort, Entscheidungen zu treffen und Aufgaben weiterzugeben.

Viele Organisationen funktionieren heute jedoch anders. Wir sprechen über flache Hierarchien, selbstorganisierte Teams, laterale Führung und Servant Leadership. Verantwortung liegt nicht mehr ausschließlich bei einzelnen Rollen, sondern verteilt sich auf Teams. Entscheidungen werden gemeinsam getroffen, Aufgaben gemeinsam getragen.

In solchen Strukturen wird Delegation unscharf. An wen delegiere ich, wenn Verantwortung im Team liegt? Was bedeutet „abgeben“, wenn ich fachlich gar nicht weisungsbefugt bin? Und was passiert, wenn Delegation nicht als Entlastung, sondern als Abschieben wahrgenommen wird?

Gleichzeitig verstehen sich viele Organisationen zunehmend als lernende Systeme. Aufgaben sind nicht nur Mittel zur Zielerreichung, sondern auch Gelegenheiten zur Entwicklung. Konzepte wie Management 3.0 [6] betonen genau diesen Aspekt: Arbeit dient nicht nur der Effizienz, sondern auch dem Lernen, der Motivation und dem Kompetenzaufbau von Mitarbeitern.

Damit wird Delegation zu einer Führungsentscheidung mit mehreren Dimensionen. Nicht jede Aufgabe, die delegierbar wäre, sollte delegiert werden. Und nicht jede Aufgabe, die belastet, lässt sich sinnvoll abgeben. Eisenhower gibt darauf keine Antworten – weil er diese Organisationslogik schlicht nicht kennt.

Fazit: Eisenhower reicht nicht mehr – aber er bleibt hilfreich

Die Eisenhower-Matrix ist kein schlechtes Werkzeug. Sie hilft, innezuhalten, Aufgaben bewusst zu betrachten und sich nicht von jeder Dringlichkeit treiben zu lassen. Das allein ist viel wert.

In meinem Arbeitsalltag reicht sie jedoch nicht mehr aus. Kognitive Überlastung, systemische Reibung, Cost of Delay und veränderte Organisationsformen lassen sich nicht sauber in vier Quadranten pressen. Dafür sind moderne Wissensorganisationen zu komplex – und Arbeit zu stark von Kontext, Abhängigkeiten und Lernen geprägt.

Was mir heute hilft, ist kein Ersatz für Eisenhower, sondern eine Ergänzung: der bewusste Blick auf Liegezeiten, auf kognitive Last – und auf die Frage, was es mich und die Organisation kostet, Dinge nicht zu entscheiden.

Eisenhower hilft mir weiterhin bei der Orientierung. Die eigentliche Priorisierung entsteht jedoch erst im Zusammenspiel aus Kontext, Verantwortung und Cost of Delay. Am Ende bleibt die Erkenntnis: Ein Werkzeug ist eben nur ein Werkzeug. Mit einem Hammer lässt sich vieles erledigen – aber nicht alles im modernen Arbeitsalltag ist ein Nagel.

Referenzen

[1] Multitasking: Switching Costs – https://www.apa.org/topics/research/multitasking 
[2] The Illusion of Urgency –  https://pmc.ncbi.nlm.nih.gov/articles/PMC10159458/ 
[3] Mintzberg, H. (1973). The nature of managerial work.
[4] Zeigarnik-Effekt – https://de.wikipedia.org/wiki/Zeigarnik-Effekt 
[5] Reinventing Organisations – https://www.reinventingorganizations.com/ 
[6] Management 3.0 – https://management30.com/ 

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Manuelle Software-Releases stellen eine häufige Quelle für Belastungen und Ineffizienz in Entwicklungsteams dar. Der Prozess umfasst oft nächtliche Deployments, manuelle Checklisten und die mühsame Erstellung von Changelogs. Dieser risikobehaftete, manuelle Arbeitsablauf birgt nicht nur ein erhebliches Potenzial für menschliche Fehler, sondern kann auch eine „Release Anxiety“ begünstigen, welche agile Entwicklungszyklen verlangsamt. Die Entscheidung, an einem Freitagnachmittag einen kritischen Fix zu mergen, wird dadurch häufig verzögert.

Ein idealer Workflow würde es jedoch ermöglichen, dass jeder Merge in den Main-Branch sicher einen neuen, korrekt versionierten Release auslöst, komplett mit strukturierten, automatisch generierten Release Notes. Dies ist nicht nur ein Prinzip moderner CI/CD-Praktiken, sondern eine erreichbare Realität. Durch die Nutzung einer strukturierten Commit History können Software-Releases zu einem routinierten, vorhersagbaren und vollständig automatisierten Prozess werden.

Dieser Artikel bietet eine technische Anleitung, um dieses Automatisierungsniveau durch die Implementierung der “Conventional Commits”-Spezifikation und des semantic-release-Tools zu erreichen.

Das Kernprinzip: Die Steuerung des Releases durch die Commit History

Der Schlüssel zu dieser Automatisierung liegt in einem konzeptionellen Wandel: Die Git Commit History wird nicht mehr nur als Protokoll von Änderungen betrachtet, sondern als die alleinige Quelle der Wahrheit für die Versionierung. Anstatt dass ein Entwickler entscheidet, ob eine Änderung einen Patch-, Minor- oder Major-Release rechtfertigt, wird diese Entscheidung direkt aus der Historie des Codes abgeleitet.

Der daraus resultierende Vorteil ist signifikant: Der Release-Prozess wird von subjektiven Entscheidungen entkoppelt und zu einer direkten, logischen Konsequenz der geleisteten Arbeit. Jeder Commit trägt eine eigene semantische Bedeutung, wodurch die Versionsnummer zu einem vorhersagbaren Ergebnis anstatt einer Schätzung wird. Diese Philosophie bildet die Grundlage der Automatisierung.

Die Grundlage: Etablierung eines Standards für Commit-Nachrichten

Die Voraussetzung für jede Automatisierung ist die Etablierung einer standardisierten, maschinenlesbaren Sprache für die Kommunikation. Die Conventional Commits-Spezifikation bietet einen solchen Standard, indem sie eine klare und verbindliche Struktur für Git Commit Messages vorschreibt, die Mehrdeutigkeiten beseitigt und die Absicht jeder Änderung explizit macht.

<type>[optionaler scope]: <description>

[optionaler body]

[optionale(r) footer]

Der type-Bezeichner ist die entscheidende Komponente, die die Auswirkung eines Commits auf die Versionierung gemäß den Prinzipien des Semantic Versioning diktiert:

• fix: Kennzeichnet eine Fehlerbehebung, die ein Problem in der Codebasis korrigiert. Dies entspricht einem Patch Release (z. B. 1.0.0 -> 1.0.1).
• feat: Bezeichnet die Einführung eines neuen Features, das Funktionalität hinzufügt. Dies entspricht einem Minor Release (z. B. 1.0.1 -> 1.1.0).
• feat! oder fix!: Signalisieren eine nicht abwärtskompatible Änderung (ein „Breaking Change“). Dieser Indikator erfordert einen Major Release (z. B. 1.1.0 -> 2.0.0).

Commits mit anderen Typen wie docs, chore, style, refactor oder test sind für die Wartung der Codebasis unerlässlich, lösen jedoch keine Anpassung der Versionsnummer aus. Diese Unterscheidung ist entscheidend, da sie sicherstellt, dass das für den Benutzer sichtbare Changelog auf wertschöpfende Änderungen, nämlich neue Features und Fehlerbehebungen, konzentriert bleibt. Dieser disziplinierte Ansatz führt zu einer transparenten und vorhersagbaren Git History.

Der Autopilot: Orchestrierung des Release-Prozesses mit semantic-release

Mit einer strukturierten Commit History kann der Release-Prozess mithilfe von Tools wie semantic-release automatisiert werden. Dieses Dienstprogramm fungiert als Orchestrator des Release-Workflows und integriert die Git History mit dem Paketmanager des Projekts und dem Repository-Host.

semantic-release automatisiert den gesamten Package Release Workflow, der die Bestimmung der nächsten Versionsnummer, die Erstellung von Release Notes und die Veröffentlichung des Pakets umfasst.

Das Tool analysiert die Commit History des Projekts, um die nächste semantische Version abzuleiten, und führt anschließend eine konfigurierbare Abfolge von Release-Schritten aus. Obwohl es als Node.js-Paket vertrieben wird, bietet seine plugin-basierte Architektur die Flexibilität, Projekte zu unterstützen, die in allen gängigen Programmiersprache entwickelt wurden. Die folgenden Abschnitte demonstrieren die Anwendung innerhalb eines Spring-Boot-Projekts.

Praktische Implementierung: Eine schrittweise Anleitung

Die Konfiguration lässt sich in drei Hauptschritte unterteilen.

Schritt 1: Vorbereitung des Gradle-Builds (gradle.properties)

Das gradle-semantic-release-plugin benötigt einen festgelegten Ort, um die Version des Projekts zu aktualisieren. Die Datei gradle.properties erfüllt diesen Zweck effektiv. Die Entkopplung der Versionsnummer in eine Properties-Datei ist eine empfohlene Praxis, da sie externen Tools ermöglicht, die Version zu lesen und zu schreiben, ohne komplexe Build-Skripte parsen zu müssen.
gradle.properties

version = 0.0.0

Schritt 2: Konfiguration des Release-Workflows (.releaserc.yml)

Diese Konfigurationsdatei definiert die genaue Abfolge der Operationen, die semantic-release ausführen wird.

.releaserc.yml

release:
  branches:
    - 'main'
preset: 'conventionalcommits'
plugins:
  - '@semantic-release/commit-analyzer'
  - '@semantic-release/release-notes-generator'
  - - '@semantic-release/changelog'
    - changelogFile: 'CHANGELOG.md'
      changelogTitle: '# Changelog'
  - - '@semantic-release/github'
    - assets:
        - path: 'CHANGELOG.md'
          label: 'Changelog'
  - 'gradle-semantic-release-plugin'
  - - '@semantic-release/git'
    - assets:
        - 'CHANGELOG.md'
        - 'gradle.properties'

Die Anweisungen in dieser Datei sind wie folgt zu verstehen:

• branches: Beschränkt die Ausführung des Release-Prozesses auf Commits im main-Branch.
• preset: Ermöglicht das Einbinden von vordefinierten Konfigurationen. Hier wird eine auf die Conventional-Commits-Konvention abgestimmte Konfiguration genutzt.
• plugins: Definiert die geordnete Pipeline von Aktionen:

• commit-analyzer: Analysiert Git-Commits seit dem letzten Release-Tag, um den erforderlichen Release-Typ (Major, Minor oder Patch) zu bestimmen.
• release-notes-generator: Erstellt strukturierte Release Notes aus den relevanten Commit-Nachrichten.
• changelog: Fügt die generierten Notes an eine CHANGELOG.md-Datei an und pflegt so eine beständige Aufzeichnung der Änderungen.
• github: Erstellt einen offiziellen, getaggten Release auf der GitHub-Plattform und fügt angegebene Assets, wie das Changelog, hinzu.
• gradle-semantic-release-plugin: Führt sprachspezifische Aufgaben aus, in diesem Fall die Aktualisierung der Version in gradle.properties und die Ausführung des publish-Tasks.
• git: Committet die geänderten Dateien (CHANGELOG.md, gradle.properties) zurück in das Repository, um dessen Zustand mit dem neuen Release zu synchronisieren.

Schritt 3: CI/CD-Integration (GitHub Actions)

Schließlich ist eine CI-Pipeline erforderlich, um den Release-Workflow bei einem Push in den main-Branch auszulösen. Der folgende GitHub-Actions-Workflow realisiert dies.

.github/workflows/release.yml

name: Release
on:
  push:
    branches:
      - main
permissions:
  contents: read
jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    permissions:
      contents: write
      issues: write
      pull-requests: write
      id-token: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Node einrichten
        uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
      - name: Install dependencies
        run: |
          npm install -g \
            semantic-release \
            @semantic-release/git \
            @semantic-release/changelog \
            conventional-changelog-conventionalcommits \
            gradle-semantic-release-plugin
      - name: Release durchführen
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release

Dieser Workflow installiert semantic-release und seine Plugins und führt dann den Release-Prozess aus. Der Parameter fetch-depth: 0 ist von entscheidender Bedeutung, da er sicherstellt, dass die gesamte Git History zur Analyse verfügbar ist. Der permissions-Block gewährt dem Job ausreichende Berechtigungen, um Releases zu erstellen und Dateien zurück in das Repository zu committen.

Fazit: Die strategischen Vorteile der Release-Automatisierung

Die Implementierung dieser automatisierten Release-Pipeline führt zu erheblichen strategischen Vorteilen. Sie eliminiert manuellen Aufwand und das Potenzial für menschliche Fehler im Versionierungs- und Release-Prozess. Die Praxis, Versionsnummern zu schätzen und Changelogs manuell zusammenzustellen, wird durch ein deterministisches, automatisiertes System ersetzt.

Diese Transformation bewirkt mehr als nur eine Zeitersparnis; sie verbessert den Softwareentwicklungszyklus grundlegend. Sie ermöglicht eine höhere Deployment-Frequenz mit größerem Vertrauen, was eine schnellere Bereitstellung von Features und Fehlerbehebungen erlaubt. Die mit Release-Ereignissen verbundene Anspannung wird durch die Effizienz von Continuous Delivery ersetzt. Die Hauptverantwortung des Entwicklungsteams reduziert sich auf die Aufrechterhaltung einer hohen Standard an Commit-Hygiene; der Release-Mechanismus übernimmt die übrigen Aufgaben.

Daniel Schock

Senior Software Engineer

Daniel ist ein erfahrener Fullstack-Entwickler und DevOps-Spezialist mit einem klaren Schwerpunkt auf der Backend-Entwicklung mit Java und Kotlin. Seine Expertise wird durch praktische Erfahrung in der Frontend-Entwicklung mit Vue.js abgerundet. Er verfügt über umfassende Kenntnisse in der Konzeption von CI/CD-Pipelines sowie im Einsatz von Cloud-Technologien wie Kubernetes und AWS, die er erfolgreich in den Branchen Versicherung, Logistik und E-Commerce einsetzte. Daniel arbeitet bevorzugt in agilen Umgebungen und zeichnet sich durch seine analytische Denkweise und hohe Problemlösungskompetenz aus.

d.schock@atra.consulting    

Digitale Inklusion als Wettbewerbsvorteil

In einer zunehmend digitalisierten Welt ist Barrierefreiheit kein nettes Extra mehr – sie ist eine Notwendigkeit. Unternehmen, die ihre Websites und Online-Shops nicht für alle Nutzergruppen zugänglich machen, schließen Millionen potenzieller Kunden aus, riskieren rechtliche Konsequenzen und verschenken wirtschaftliches Potenzial.

Dabei bietet eine barrierefreie Website nicht nur einen gesellschaftlichen Mehrwert, sondern sorgt auch für mehr Reichweite, eine bessere Nutzererfahrung und langfristige Wettbewerbsfähigkeit. Doch was bedeutet digitale Barrierefreiheit konkret, welche gesetzlichen Anforderungen müssen Unternehmen erfüllen und warum sollten sie sich aktiv darum kümmern?

Dieser Artikel gibt Ihnen einen umfassenden Überblick darüber, warum Web Accessibility (A11Y) ein entscheidender Erfolgsfaktor für Unternehmen ist.

Was bedeutet digitale Barrierefreiheit?

Barrierefreiheit im Web bedeutet, dass digitale Inhalte von allen Menschen uneingeschränkt genutzt werden können – unabhängig von körperlichen oder kognitiven Einschränkungen.

Betroffene Nutzergruppen:

• Menschen mit kognitiven Einschränkungen → Profitieren von klar strukturierten, leicht verständlichen Texten.
• Sehbehinderte und blinde Menschen → Nutzen Screenreader, Braille-Displays oder benötigen hohe Kontraste.
• Menschen mit motorischen Einschränkungen → Navigieren per Tastatursteuerung oder Spracherkennung.
• Hörgeschädigte Nutzer → Sind auf Untertitel und Transkriptionen für audiovisuelle Inhalte angewiesen.
  

Eine barrierefreie Website berücksichtigt all diese Aspekte und stellt sicher, dass jeder Besucher die Inhalte gleichermaßen erfassen und bedienen kann.

Wirtschaftlicher Nutzen von Barrierefreiheit

Oft wird Barrierefreiheit als zusätzliche Belastung betrachtet. Tatsächlich bringt sie jedoch messbare Vorteile mit sich:

Größere Zielgruppe & höhere Reichweite

• Über 15% der Weltbevölkerung leben mit einer Behinderung – das sind Millionen potenzieller Kunden, die durch Barrierefreiheit besser erreicht werden können.
• Ältere Menschen profitieren ebenfalls von besserer Lesbarkeit und einfacherer Navigation.
• Unternehmen, die Barrierefreiheit ignorieren, verlieren diese potenziellen Kunden an die Konkurrenz.
  

Höhere Usability für alle Nutzer

• Strukturierte Inhalte, gute Lesbarkeit und intuitive Navigation kommen allen Kunden zugute.
• Barrierefreiheit verbessert die User Experience (UX) und erhöht die Verweildauer auf der Website.
  

SEO & Google-Ranking verbessern

• Google bevorzugt barrierefreie Websites – ein besseres Ranking sorgt für mehr Sichtbarkeit.
• Klare Seitenstrukturen, alternative Bildbeschreibungen und schnelle Ladezeiten steigern die Auffindbarkeit.
  

Mehr Conversions & Umsatz

• Untersuchungen zeigen, dass gut nutzbare Websites eine höhere Conversion-Rate erzielen.
• Durch optimierte Bestellprozesse in Online-Shops können mehr Kunden den Kauf abschließen..

Rechtliche Anforderungen: Was Unternehmen wissen müssen

EU-Richtlinie & BFSG: Ab 2025 gilt eine gesetzliche Pflicht

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 in deutsches Recht um. Ab Juni 2025 müssen viele private Unternehmen digitale Barrierefreiheit gewährleisten, darunter:

• Online-Shops
• Banken und Versicherungen
• Telekommunikationsanbieter
• E-Book- und Streaming-Dienste
• Software- und Ticketing-Plattformen
  

Verstöße können zu Abmahnungen, Geldbußen und Reputationsschäden führen. Unternehmen sollten daher jetzt handeln, um ihre digitalen Angebote rechtzeitig anzupassen.

Fazit

Digitale Barrierefreiheit ist kein freiwilliges Extra – sie wird zur Pflicht. Doch abgesehen von der gesetzlichen Notwendigkeit bietet sie signifikante wirtschaftliche Vorteile, von mehr Reichweite bis hin zu besseren Conversion-Raten. Wer frühzeitig investiert, sichert sich einen Wettbewerbsvorteil und vermeidet rechtliche Risiken.

Lesen Sie im zweiten Teil der Serie, welche praktischen Maßnahmen Sie ergreifen können, um Ihre Website barrierefrei zu machen.

Unsere Expertise

Mit unserer erfahrungsreichen Expertise unterstützen wir Unternehmen bei der barrierefreien Gestaltung ihrer digitalen Angebote. Unsere Dienstleistungen umfassen:

• Barrierefreiheits-Audits: Wir prüfen Ihre Website auf Konformität mit den WCAG-Standards.
• Strategieberatung: Wir helfen Ihnen, Barrierefreiheit strategisch in Ihre digitalen Prozesse zu integrieren.
• Technische Umsetzung: Von der Optimierung bestehender Seiten bis hin zur Erstellung neuer, barrierefreier Lösungen.
  

Besuchen Sie auch gerne für mehr Informationen unsere Website speziell zu diesem Thema!

atra.consulting/barrierefreiheit

Barrierefreiheit

Machen Sie Ihre Website barrierefrei – für mehr Reichweite und rechtliche Sicherheit! Wir helfen Unternehmen, digitale Angebote inklusiver, zugänglicher und gesetzeskonform zu gestalten.

Lassen Sie uns gemeinsam die digitale Welt inklusiver gestalten!

In einem kostenlosen Erstgespräch analysieren wir den aktuellen Stand Ihrer Website und zeigen Ihnen konkrete Maßnahmen auf, wie Sie sie für eine breitere Zielgruppe zugänglich machen können. So verbessern Sie nicht nur die User Experience, sondern stärken auch Ihre Marke und steigern Ihre Reichweite.

Kontaktieren Sie uns jetzt und machen Sie den ersten Schritt zu einer digitalen Zukunft, die niemanden ausschließt!

Ihr Ansprechpartner

Timo Kaiser

Senior Software Engineer Consultant
Web-Entwickler / A11Y-Spezialist

t.kaiser@atra.consulting
+49 1520 2380444

Timo kontaktieren

Die Auswahl an wohltätigen Organisationen und karitativen Einrichtungen ist riesig. Alleine eine kurze Online-Suche nach dem Stichwort „Weihnachtsspende“ ergibt unzählige Treffer – mit vielen wunderbaren Projekten, die jede Unterstützung verdient hätten. Doch die schiere Vielfalt macht es schwierig, gezielt auszuwählen.

Da wir als IT-Beratungsgruppe täglich im technologischen Umfeld arbeiten, möchten wir unsere Spende deshalb auf einen Bereich konzentrieren, der direkt zu unserem beruflichen Alltag passt. Unsere Wahl fiel auf Open-Source-Software (OSS). Durch OSS werden nicht nur moderne Technologien ermöglicht, sondern auch Innovationen und Stabilität in der IT-Infrastruktur gefördert. Uns ist es wichtig, auch hier einen Beitrag zu leisten und uns für eine „karitative Technologie-Spende“ zu engagieren, die sich für viele Menschen langfristig positiv auswirken kann.

Das Rückgrat unserer digitalen Welt

Open-Source-Software ist das unsichtbare Rückgrat der digitalen Welt, auf das sich viele unserer Projekte und Technologien stützen. Oft denken wir gar nicht daran, dass hinter dieser Software kleine Entwicklerteams oder sogar Einzelpersonen stehen, die diese Infrastruktur ehrenamtlich und ohne finanzielle Rückendeckung aufrechterhalten.

Die Open-Source-Community sieht sich einem Spannungsfeld gegenüber: Auf der einen Seite ist “ihre Software” enorm erfolgreich und weit verbreitet. So läuft Android, ein auf dem Linux-Kernel basierendes Betriebssystem, auf über 2 Milliarden Geräten weltweit. Linux selbst, mittlerweile 25 Jahre alt, ist aus der digitalen Welt nicht mehr wegzudenken. Sein Einsatzgebiet reicht von Alltagsgeräten wie Smartphones und Druckern über Webserver und Cloudinfrastruktur bis hin zu Supercomputern, wo es auf 498 der 500 leistungsstärksten Systemen läuft. Die Weltherrschaft von Linux ist unbestritten.

Linux und Android sind zwar bekannte Beispiele, aber bei weitem nicht die einzigen. Die Datenbank SQLite, beispielsweise, ist außerhalb der IT-Welt kaum jemandem ein Begriff. Trotzdem wird sie Schätzungen zufolge auf über einer Billion Geräten aktiv genutzt.

Schattenseiten: Herausforderungen in der Open-Source-Welt

Obwohl Open-Source-Software das unsichtbare Rückgrat unserer modernen digitalen Welt darstellt, gibt es auch weniger beachtete Schattenseiten. Dieses Rückgrat ruht auf den Schultern engagierter Freiwilliger, die ihre Arbeit mit Leidenschaft und ohne kommerziellen Anreiz der Allgemeinheit zur Verfügung stellen. Doch von dieser Arbeit können sie oft nicht leben. Kritische Software-Infrastruktur wird deshalb häufig von Einzelpersonen in späten Nachtstunden oder am Wochenende – zusätzlich zu ihrem regulären Job – entwickelt und gepflegt.

Ein markantes Beispiel hierfür ist die Programmbibliothek OpenSSL, die rund zwei Drittel des gesamten Internetverkehrs verschlüsselt und damit eine Schlüsselrolle in der digitalen Sicherheit einnimmt. Ein über Jahre unentdeckter Fehler in OpenSSL führte zum berühmten Heartbleed-Bug, der eine erhebliche Sicherheitslücke darstellte und private Daten im Internet anfällig für Angriffe machte. Nach der Behebung des Bugs machte das Entwicklungsteam deutlich auf die strukturellen Probleme in der Open-Source-Welt aufmerksam und bat um Hilfe.

Ein etwas aktuelleres Beispiel wurde von Heise gar als größtes Fiasko in der Geschichte des Internets bezeichnet, dem wir gerade so entgangen sind. Vermutlich staatliche Akteure nutzten eine technisch hochentwickelte Methode, um die Paketierungssoftware XZ zu kompromittieren. Dabei setzten sie auf raffiniertes Social Engineering, indem sie die angeschlagene psychische Gesundheit von Lasse Collin, dem Hauptentwickler der Software, gezielt ausnutzten. Diese Aktion, die zunächst unscheinbar wirken mag, hätte fast eine Backdoor in nahezu jedes System weltweit geöffnet.

Open Source: Stärke durch Transparenz, aber wer trägt die Verantwortung?

An dieser Stelle möchten wir betonen: Open Source Software ist nicht per se unsicherer oder weniger nachhaltig als kommerzielle Software (Closed Source Software). Ganz im Gegenteil – die breite und öffentliche Aufarbeitung, wie im Fall von XZ, sehen wir als eine Stärke, die langfristig Sicherheit und Stabilität fördert. Gleichzeitig wirft dies aber auch die wichtige Frage nach einer fairen Lastenverteilung auf – ein Punkt, der in folgendem xkcd-Comic auf amüsante Weise illustriert wird.

Ob insbesondere große Unternehmen, alleine in Deutschland nutzen 71% dieser Open-Source-Software, sowie Staaten hier zum Erhalt unseres digitalen Rückgrats genug investieren und „zurückgeben“, ist ein sehr berechtigter Aspekt dieser Frage, bspw. erst kürzlich wieder von der Wikimedia gestellt.

Das Spannungsfeld zwischen der erfolgreichsten Idee der IT-Geschichte und vielen engagierten “stillen Helden” ist auch hier offensichtlich. Glücklicherweise werden auch Themen wie Burnout immer offener diskutiert.

Weihnachtsspende: Immer noch viel Auswahl

Nun gibt es auch bei der Suche nach geeigneten Spendenzielen im Open-Source-Bereich unzählige inspirierende Organisationen und Projekte, die jede Unterstützung verdienen. Statt selbst eine Auswahl zu treffen, haben wir innerhalb von atra.consulting eine kleine Umfrage gestartet. Der Rahmen war einfach: Für jedes Teammitglied stand eine Spendensumme von 50 € zur Verfügung. Alle Kolleginnen und Kollegen waren eingeladen, ihr persönliches Herzensprojekt vorzuschlagen. Anschließend wurde gemeinsam über die eingereichten Vorschläge abgestimmt.

So starten wir die Weihnachtszeit nun mit Spenden an folgende Projekte:

Signal – Der sichere, E2E-verschlüsselte Open-Source-Messenger überzeugte unser Team auf ganzer Linie. Neben innovativer Entwicklung, etwa im Bereich Post-Quantum-Verschlüsselung, leistet die Signal Foundation unschätzbare Arbeit. Mit Abstand auf Platz 1 erhält Signal 50 % der Spendensumme.

Wikipedia – Zwar keine klassische Open-Source-Software, aber ein unverzichtbares Open-Knowledge-Projekt. Es bereichert unseren Alltag und ist eine essenzielle Grundlage, auch für die Entwicklung moderner Technologien wie LLMs. Wikipedia erhält 30 % der Spendensumme.

Notepad++ – Ein einfacher, aber wertvoller Texteditor, der für viele von uns tägliches Werkzeug ist. Notepad++ erhält 20 % der Spendensumme und würdigt damit die Bedeutung kleiner, effektiver Tools.

Mit unserer Spendenaktion möchten wir nicht nur einen Beitrag leisten, sondern auch das Bewusstsein für die Bedeutung von Open-Source-Software schärfen. Wir laden alle ein, sich dieser Idee anzuschließen und die Open-Source-Community aktiv zu unterstützen.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Einleitung

Bei der Besetzung von Rollen in IT-Projekten ist eine gewisse Findungsphase mit dem Auftraggeber nicht unüblich. Während viele Rollen im Lehrbuch (recht) eindeutig definiert sind, spricht die Praxis oftmals eine andere Sprache. Eine besonders komplexe Rolle hierbei ist die des Softwarearchitekten, bei welcher sich Anforderungen und Erwartungen von Organisation zu Organisation teils stark unterscheiden. Dies hat sicherlich auch damit zu tun, dass selbst der Begriff von Softwarearchitektur in der Literatur nicht einheitlich und erst recht nicht präzise definiert ist. Gleichzeitig trägt die Rolle aber wesentlich zum Erfolg von IT-Projekten bei. Grund genug für uns, den vielen Facetten von Softwarearchitektur eine kleine Blogserie zu widmen.

Einleiten wollen wir diese Blogserie mit einer nicht ganz ernst gemeinten Betrachtung verschiedener (Stereo-)Typen von Softwarearchitekten, wie sie die meisten Menschen, die sich im Kontext von IT-Projekten bewegen, wohl schon erlebt haben. Die durchaus sinnvollen Unterscheidungen zwischen Enterprise, Solution und Technical Architecture klammern wir an dieser Stelle erst einmal bewusst aus, da sich unserer Erfahrung nach untenstehende Typen auf eigentlich jedem Abstraktionslevel finden lassen. Aber Achtung – der Beitrag kann Spuren von Ironie enthalten. 

Der Powerpoint-Architekt

Für ihn bestehen Softwaresysteme aus Kästchen und Pfeilen. Alles andere sind doch auch nur lästige Implementierungsdetails. Wird von agilen Teams häufig nach oben weggelobt und zeichnet seine Powerpoints nun auf höherer Ebene.

Der Elfenbeinturm-Architekt

Durchaus verwandt mit dem Powerpoint-Architekten befindet sich der Elfenbeinturm-Architekt im… nun ja, in seinem persönlichen Elfenbeinturm. Oftmals zeichnen Elfenbeinturm-Architekten sich gleichzeitig durch ein tiefes, zumeist akademisch geprägtes Fachwissen auf der einen und eine komplette Ignoranz für die (Projekt-)Bedürfnisse der Entwicklungsteams auf der anderen Seite aus. Liebt Gremien, in welchen die Entwicklungsteams sich ihre Architekturen abnehmen lassen müssen. Oder es zumindest versuchen. Der natürliche Feind agiler Teams.

Der Chronisten-Architekt

Sieht sich als Wächter der Dokumentation, welche in ihrer Bedeutung der Bibliothek von Alexandria quasi in nichts nachsteht. Etwas, was nicht ausführlich dokumentiert ist, existiert für ihn nicht und kann auf gar keinen Fall funktionieren. Idealerweise wird die Architektur und ihre Dokumentation in mehrstufigen Gremien freigegeben. Im Gegensatz zum Elfenbeinturm-Architekten sieht der Chronisten-Architekt seine Rolle aber eher in der Vorbereitung und Dokumentation der Gremienarbeit.

Der Podcast-Architekt

Hört wirklich jeden Architektur – und Technologie-Podcast auf dem Markt. In mehr als einer Sprache. Der Podcast-Architekt predigt die neuesten Technologien und Methoden und versucht, jeden in seinem Umfeld davon zu überzeugen. Hält sich auch liebend gerne auf Konferenzen und Meetups auf. Seine Wahrnehmung in den Projektteams variiert stark – manche lieben ihn und seine Impulse, manche möchten doch einfach nur das Projekt zu Ende bringen.

Der Prototypen-Architekt

Dieser Architekten-Typus ist der natürliche Gegenpart zum Powerpoint-Architekten. Architektur findet für ihn direkt im Code statt, neue Pattern oder Ideen stellt er am liebsten als Prototyp direkt in seinem Repo zur Verfügung. Die Entwicklungsteams lieben ihn, auch wenn sein sonstiges Umfeld sich durchaus ein wenig mehr Dokumentation und Struktur wünschen würde.

Der U-Boot-Architekt

Nicht zu verwechseln mit dem Elfenbeinturm-Architekten, ist sein natürliches Wirkungs-Habitat der Besprechungsraum. Hier weiß er zu brillieren und durch die geschickte Platzierung von Fragen und Prüfaufträgen jede noch so kleine Entscheidung zielsicher zu torpedieren. Nur um dann wieder abzutauchen – bis zum nächsten Mal.

Der basisdemo­kra­tische Architekt

Architektur ergibt sich für ihn nur evolutionär aus der Diskussion im Team und hat sich dem Code unterzuordnen. Vorabentschei­dungen sind unbedingt zu vermeiden, zentrale Beschlüsse oder übergreifende Einschränkungen werden als persönlicher Affront aufgefasst. Auf diese Weise hat der basisdemokratische Architekt immer ein lokales Optimum fest im Blick – oftmals jedoch nicht das große Ganze. 

Uns selbst laufen eigentlich alle oben genannten Typen regelmäßig in Rein- oder Mischform in unseren Projekten über den Weg. Sehr gerne denke ich an einen großen Kunden zurück, bei dem der Auf­trag­geber selbst von 3-6 Monaten Onboarding ausge­gangen ist, um die komplexen Dokumentations- und Prozess­anforderungen an die Entwicklung der Software­architektur zu verinnerlichen. Ein typischer Fall von (in diesem Fall gewollten) Chronisten-Architekten. 

Aber was lernen wir nun aus den verschiedenen Typen von Softwarearchitekten? Auch wenn die Darstellung bewusst überspitzt war, verdeutlicht die Betrachtung sehr schön, mit welchen komplexen Anforderungen sich ein Softwarearchitekt konfrontiert sieht. Persönlich mag ich das Bild des Softwarearchitektur-Aufzuges von Gregor Hohpe, in welchem der Architekt sich vom Maschinen­raum im Keller (Technik, Programmiersprache, Design Pattern) bis zum Vorstands-Penthouse auf dem Dach (IT-Transformation, Organisationsentwicklung) bewegt. Auch wenn man durchaus hinterfragen kann, ob es sinnvoll ist, so viele Aufgaben und Anforderungen in eine einzige Rolle zu projizieren. Im nächsten Blogpost beschäftigen wir uns etwas ausführlicher damit, was Softwarearchitektur für uns eigentlich bedeutet – ganz ohne Ironie.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Die in diesem Artikel verwendeten Bilder wurden mit Hilfe von DALL·E 2, einer KI zur Bildgenerierung, erstellt.

Inhalt:

• Einleitung
• Interner Softwareentwickler – externer Berater im Anwenderunternehmen
  • Personalnebenkosten
  • Produktivität
• Fazit

Einleitung

Wenn man in Umfeldern tätig ist, in denen sowohl angestellte Mitarbeiter als auch externe Berater eingesetzt werden, wird man früher oder später mit der Frage konfrontiert, warum der Externe im Vergleich zum Angestellten so teuer sei. Hier wird dann häufig der Tagessatz eines externen Beraters, welcher beispielsweise als Java-Entwickler für einen Kunden tätig ist, mit 20 Arbeitstagen multipliziert und mit dem Bruttomonatsgehalt eines bei dem Kunden angestellten Java-Entwicklers verglichen.

Für einen angestellten Java-Entwickler sind das derzeit durchschnittlich 70.250 € [1] pro Jahr. Das Beratungshonorar eines externen Beraters kann erheblich variieren, ein Freelancer ist dabei üblicherweise günstiger als ein über eines der großen Beratungshäuser, wie zum Beispiel Accenture, eingesetzter Berater. Ein Durchschnittswert von 1.000 € pro Tag für einen externen Berater erscheint aus unserer Erfahrung realistisch. 20.000 € im Monat für einen externen Berater im Vergleich zu 5.854 € für einen angestellten Softwareentwickler wirken auf den ersten Blick nachvollziehbarerweise unverhältnismäßig – bei dieser Betrachtungsweise würde ein Angestellter nicht mal ein Drittel eines Externen kosten. Wieso machen Unternehmen das also?

»Für jedes Problem gibt es eine Lösung, die einfach, klar und falsch ist.« –H. L. Mencken

Wie so häufig ist die Realität nicht einfach und es nur mit der „Äpfel mit Birnen vergleichen“-Metapher abzutun, auch wenn sie hier zutrifft, wird der Sache nicht gerecht. Deshalb werden wir die Thematik im Folgenden einmal genauer beleuchten.

Entscheidend für entsprechende Kostenvergleiche ist zunächst die Art und Weise der Kalkulation im Unternehmen. Beim Einsatz von Softwareentwicklern, um den es hier geht, ist die Frage, ob das Unternehmen mit Softwareentwicklung Geld verdient oder die Softwareentwicklung Mittel zu einem (anderen) Zweck ist. Handelt es sich also um ein IT- beziehungsweise Softwareunternehmen oder – aus der Perspektive der IT beziehungsweise Softwareentwicklung – um ein Anwenderunternehmen? Buchhalterisch gefragt: Ist die Softwareentwicklung Aktiv- oder Passivposten in der Bilanz des Unternehmens, Profit- oder Cost-Center? Betriebswirtschaftlich weiter gefasst: Handelt es sich bei der Softwareentwicklung um einen Kern- oder Hilfsprozess für das Unternehmen?

Abbildung 1: Exemplarische Prozessübersicht eines Handelsunternehmens

Im obigen Beispiel haben wir die vereinfachte Prozesslandschaft einer Handelsorganisation als ein Anwenderunternehmen dargestellt, welche im Wesentlichen aus den beiden Kernprozessen Einkauf und Verkauf besteht; die IT ist hier üblicherweise (noch) nur Mittel zum Zweck, also ein unterstützender Prozess beziehungsweise eine Kostenstelle.

Natürlich hat sich gerade in den vergangenen 10 Jahren diesbezüglich in deutschen Handelsunternehmen viel getan. Getrieben durch Amazon und die Digitalisierung kennen wir auch klassische Handelsunternehmen, die die Umsatz-Parität zwischen online und offline erreicht haben und mehr als 1.000 Mitarbeiter in ihren Technologiebereichen beschäftigen. Diese Firmen sind sicherlich nicht mehr als reine Handelsorganisationen zu verstehen. Ob sie schon wie ein reines Technologieunternehmen kalkulieren, lassen wir für diese Betrachtung außen vor.

Je nachdem, ob die Softwareentwicklung Kern- oder Hilfsprozess für eine Organisation ist, wird entsprechend anders kalkuliert. Deshalb differenzieren wir in unserer weiteren Betrachtung auch entsprechend nach Anwender- und Technologieunternehmen und zeigen anhand einer Vollkostenkalkulation zunächst für ein Anwenderunternehmen auf, was ein angestellter Softwareentwickler wirklich kostet.

Die einfachste Form eines Technologieunternehmens ist ein freischaffender Softwareentwickler. Auch hier erleben wir häufig sehr vereinfachende Darstellungen betriebswirtschaftlicher Realitäten, die dann eher in die Richtung gehen, dass man als Freelancer doch so viel mehr verdienen würde als ein angestellter Softwareentwickler. Da dies im Prinzip nur die andere Seite der eingangs geschilderten Problematik darstellt, zeigen wir in einem zweiten Schritt anhand eines Soloselbständgen auf, was es aus Sicht eines Technologieunternehmens bei der Vollkostenkalkulation zu beachten gilt.

Dass der eingangs gezeigte Vergleich des Monatsgehalts mit dem Beratungshonorar betriebswirtschaftlich schlicht falsch ist, zeigen auch Einblicke aus unserer eigenen Managementpraxis in entsprechenden Unternehmen. Zumindest ab einer gewissen Ebene und in den Finanzabteilungen größerer Unternehmen ist man sich natürlich bewusst, dass die Kosten eines Angestellten mehr umfassen als nur sein Gehalt. In dieser sogenannten Vollkostenbetrachtung kalkulierte man beispielsweise schon in den 2000er Jahren in der Telekommunikationsbranche mit ~750 € pro Tag für einen angestellten IT-Experten, wie wir aus entsprechenden Mandaten wissen. Aus der Finanzdienstleistungsbranche liegen uns aus dem vergangenen Jahr kalkulatorische Kosten angestellter Softwareentwickler in Höhe von 900 € pro Tag vor, von einem anderen Unternehmen wissen wir, dass IT-Experten intern sogar mit weit über 1.000 € verrechnet werden. Das Beratungshonorar eines externen IT-Spezialisten in Höhe von rund 1.000 € pro Tag unterscheidet sich also scheinbar doch gar nicht so sehr von den „echten“ beziehungsweise kalkulatorischen Vollkosten eines angestellten IT-Experten in einem Anwenderunternehmen.

Über die Hintergründe, warum scheinbar wissentlich in Organisationen falsch kalkuliert (oder kommuniziert) wird, können wir nur spekulieren. In Preisverhandlungen mag die (falsche) Vereinfachung noch als Taktik durchgehen. Des Weiteren lässt sich nur vermuten, dass das durchaus vorhandene Wissen bewusst oder unbewusst nicht an alle Stellen im Unternehmen weitergegeben wird. Hier kann dieser Beitrag vielleicht für ein wenig Aufklärung sorgen.

Da die Softwareentwicklung den Schwerpunkt unserer Beratungstätigkeit umfasst, fokussieren wir uns hier auch entsprechend auf selbige. Die Beispiele lassen sich aber auf beliebige andere Rollen, die sowohl von eigenem Personal als auch externen Beratern in Organisationen übernommen werden, transferieren, seien es agile Coaches, IT-Projektleiterinnen, UX-Designer oder beispielsweise Business Analysten, um nur einige zu nennen.

Interner Softwareentwickler – externer Berater im Anwender­unterneh­men

Wie kommt man nun also von durchschnittlich 5.854 € Bruttomonatsgehalt eines angestellten Softwareentwicklers in einem Anwenderunternehmen auf 20.000 € kalkulatorische Vollkosten beziehungsweise externes Beratungshonorar – für die gleiche Arbeit? Zwei wesentliche Aspekte gilt es hier zu bedenken. Einerseits die weiteren Kosten neben den reinen Gehaltskosten, also die Personalnebenkosten im weitesten Sinne. Andererseits die Produktivität, also wieviel Stunden oder Tage für das Gehalt im Falle eines Softwareentwicklers dann wirklich auch für die Softwareentwicklung aufgewendet wird; der externe Berater wird ja nur bezahlt, wenn er für den Kunden tätig ist, also Software entwickelt, der Angestellte erhält sein Gehalt auch, wenn er im beispielsweise im Urlaub ist.

Personalneben­kosten

Schauen wir uns zunächst die weiteren Kosten aus Arbeitgebersicht neben dem Bruttomonatsgehalt eines Angestellten an. Als Erstes fallen für den Arbeitgeber natürlich die anteiligen Beiträge zur Sozialversicherung an, aber auch die Entgeltfortzahlung im Krankheitsfall und beispielsweise Zahlungen an aus dem Unternehmen ausscheidende Arbeitnehmer (Abfindungen) dürfen bei Angestellten nicht außer Acht gelassen werden. Gemäß statistischem Bundesamt [2] ist hierfür im Schnitt mit 23,3 % zu kalkulieren.

Da die dort angenommenen 233 € pro Jahr für Weiterbildung in der Softwareentwicklung unserer Erfahrung nach nicht ausreichen, legen wir hierfür realistischere 3.000 € pro Jahr zugrunde, circa 2.000 € für eine mehrtägige Weiterbildung und rund 1.000 € für einen zweitägigen Konferenzbesuch.

Außerdem sind die Arbeitsplatzkosten zu berücksichtigen, welche je nach Standort und Ausstattung natürlich erheblich variieren können – 1.000 € pro Monat erscheint uns hier ein realistischer Näherungswert für einen Arbeitsplatz inklusive IT-Ausstattung1. Natürlich können auch für einen externen Berater Arbeitsplatzkosten beim Kunden anfallen, wir gehen hier von dem unserer Erfahrung nach (gesetzlich) üblichen Szenario aus, bei welchem der externe Berater nur zu Besprechungen beim Kunden ist und ansonsten mit und in eigener Infrastruktur arbeitet.

Die durchschnittlichen Vollkosten eines angestellten Softwareentwicklers liegen somit bereits bei rund 8.500 € pro Monat beziehungsweise rund 100.000 € pro Jahr:

Tabelle 1: Vollkostenkalkulation eines angestellten Softwareentwicklers – Stufe I

Es geht allerdings noch weiter, denn in der Vollkostenbetrachtung ist aus Sicht eines Anwenderunternehmens zumindest auch das Management der Mitarbeiter als Kostenposition anzusetzen2. Addiert man die oben genannten Personalnebenkosten zu dem durchschnittlichen Gehalt eines Teamleiters im IT-Bereich von 78.250 pro Jahr [1], ergeben sich für selbigen monatliche Vollkosten in Höhe von 9.290 €. Da es gegebenenfalls mehrere Führungsebenen gibt, die mit jeder Stufe mehr kosten, deren Anteil pro Mitarbeiter aber auch immer geringer wird, setzen wir als Managementkosten aus Vereinfachungsgründen 10.000 € pro Monat für einen IT-Teamleiter und die weiteren Hierarchie-Stufen an:

Tabelle 2: Vollkostenkalkulation eines angestellten Teamleiters in der IT

Wie viel dieser Managementkosten dem einzelnen Mitarbeiter zugerechnet werden, hängt von der Führungsspanne ab. In agilen Entwicklungsorganisationen besteht ein Team gemäß Amazons berühmter »Two Pizza Team«-Regel [4] zwar idealerweise aus weniger als 10 Personen, wir sehen hier regelmäßig aber auch größere Teams, so dass man als durchschnittliche Teamgröße durchaus 10 Personen ansetzen kann. Das Management eines Teams verteilt sich im agilen Kontext allerdings auf mehrere Rollen. Ein „klassischer“ Teamleiter ist hier beispielsweise nun sogenannter Chapter Lead, der sich „nur“ noch um die disziplinarische Führung seiner Mitarbeiter kümmert und dadurch unserer Erfahrung nach dann bis zu maximal 25 Mitarbeiter betreut. Dazu kommt dann üblicherweise ein Product Owner je agilem Entwicklungsteam, der sich um das Inhaltliche kümmert, also was getan wird. Für prozessuale Fragen unterstützt dann noch ein Scrum Master oder agiler Coach – unserer Erfahrung nach in der Regel zwei Entwicklungsteams.

Ein durchschnittliches agiles Entwicklungsteam mit 10 Mitarbeitern wird so also von 1,9 „Führungskräften“ unterstützt. Aus Vereinfachungsgründen setzen wir für den Product Owner und Scrum Master die gleichen Vollkosten wie für den Teamleiter an, womit sich folgenden Vollkostenkalkulation ergibt:

Tabelle 3: Vollkostenkalkulation eines angestellten Softwareentwicklers – Stufe II

Aus rund 70.000 € Jahresbruttogehalt eines angestellten Softwareentwicklers werden in der agilen Entwicklungsorganisation eines IT-Anwenderunternehmens bei Betrachtung der Personalnebenkosten und der Kosten für das Management somit Vollkosten von nahezu 125.000 € pro Jahr.

Produktivität

Wie weiter oben schon kurz geschildert, fällt das Honorar für einen externen Berater nur an, wenn er auch für seinen Kunden tätig ist. Ein Angestellter erhält sein Gehalt hingegen auch, wenn er nicht für seinen Arbeitgeber tätig ist, also bei Urlaub, Krankheit und so weiter. Um die beiden Modelle vergleichen zu können, müssen also die effektiven Arbeitstage eines Angestellten ermittelt werden.

Von den rund 250 Arbeitstagen pro Jahr sind 30 Urlaubstage und 13 Krankheitstage [5] für einen Softwareentwickler abzuziehen. Für Weiterbildung setzen wir 5 Tage an, weitere 5 Tage müssen für den gesetzlich jedem Arbeitnehmer zustehenden Weiterbildungsurlaub pro Jahr abgezogen werden, womit 197 Tage verbleiben. Ein IT-Anwenderunternehmen kann für einen angestellten Softwareentwickler also mit rund 200 Anwesenheitstagen pro Jahr kalkulieren.

Aufgrund von Mitarbeitergesprächen, Team- oder Abteilungsbesprechungen, Mitarbeiterversammlungen und sonstigen Einflüssen kann diese Zeit nicht vollständig produktiv angerechnet werden – außerdem gilt es, Parkinson’s Law zu beachten:

»Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.« –C. N. Parkinson

Die Zahlen und Quellen zu produktiver Arbeit variieren erheblich. Gemäß einem Anbieter von Bürosoftware gilt die »Faustregel […] dass 25 Prozent der Arbeitszeit unproduktiv sind. Das beinhaltet Arbeitszeit, die für Meetings, Gespräche oder andere unproduktive, aber geschäftlich wichtige Abläufe aufgewendet wird« [6]. Zu einem ähnlichen Ergebnis kommt der „Slack State of Work Report 2023”. Demnach »geben deutsche Arbeitnehmer an, dass sie knapp ein Drittel ihrer Arbeitszeit (29 Prozent) mit Aufgaben verbringen, die nicht direkt auf ihre Ziele einzahlen [10]«. Das US-Unternehmen Tower geht davon aus, dass Mitarbeiter maximal 5 Stunden am Tag produktiv sein können, weshalb dies auch ihre vertragliche Arbeitszeit ist – bei vollem Gehalt [11]; in diesem Fall wird also schon mit 37,5 % unproduktiver Arbeitszeit gerechnet. Eine Untersuchung in UK kommt sogar zu dem Ergebnis, dass aufgrund Socialmedia und anderer Ablenkungen nur 2 Stunden und 23 Minuten eines Arbeitstags produktive Arbeit sind [12] – dies entspräche fast 70 % unproduktiver Zeit. Für unsere weitere Betrachtung setzen wir den unteren Wert der verschiedenen Untersuchungen von 25 % an, was bezogen auf die oben weiter ermittelten 197 Anwesenheitstage zu 49 unproduktiven Tagen im Jahr führt – rund ein Tag pro Woche für nicht-produktive Aktivitäten klingt unserer Einschätzung nach realistisch.

Für einen angestellten Softwareentwickler ergeben sich somit rund 147 effektive oder produktive Arbeitstage pro Jahr:

Tabelle 4: Ermittlung effektive Arbeitstage in der Softwareentwicklung

Fazit

Um die Vollkosten eines angestellten Softwareentwicklers von rund 125.000 € mit dem Beratungshonorar eines Externen vergleichen zu können, müssen die effektiven Arbeitstage des Angestellten herangezogen werden. Wir setzen hierfür die oben ermittelten 147 Tage pro Jahr an, womit der kalkulatorische Tagessatz eines angestellten Softwareentwicklers in einer Vollkostenkalkulation im gezeigten Beispiel schon bei rund *850 € liegt – das vermeintliche Delta zwischen den beiden Ansätzen ist bei kaufmännisch solider Betrachtung also von zunächst dramatisch erscheinenden 70 % auf überschaubare 15 % abgeschmolzen.

Größere Organisation haben in der Regel noch mehr und höhere Kostenpositionen, beispielsweise durch zusätzliche Hierarchiestufen oder weitere Vorteile für Mitarbeiter, welche in einer Vollkostenbetrachtung auch entsprechend berücksichtigt werden müssen – aus 850 € werden so schnell 900 € und mehr pro Tag.

Und dann darf nicht vergessen werden, dass hier am Ende des Tages schließlich doch Äpfel mit Birnen verglichen werden. Externe Berater werden üblicherweise geholt, um Leistungsspitzen / Kapazitätsengpässe abzudecken und / oder Spezialwissen einzubringen. Darüber hinaus sei auch auf die Flexibilität bei ihrem Einsatz verwiesen. Ein externer Softwareentwickler ist unserer Erfahrung nach innerhalb von 2-4 Wochen im Projekt, für die Einstellung eines angestellten fallen 7,7 Monate an [13] – und manchmal, Stichwort Fachkräftemangel, findet sich schlicht gar kein passender Angestellter. Genauso schnell, wie ein Externer gefunden ist, kann sich als Anwenderunternehmen auch wieder von ihm getrennt werden – bei Angestellten fällt dies zu Recht wesentlich schwerer. Kurzfristige Budgetschwankungen lassen sich mit Externen wesentlich leichter ausgleichen – wir kennen Unternehmen, die bewusst Richtung Geschäftsjahres- und somit Budgetende mit Externen entsprechend „atmen”. Und auch über interne Versetzungen, Stellenpläne oder Ähnliches muss ich mir bei externem Personal keine Gedanken machen. Jeder, der schon mal in größeren Organisationen mit einem Betriebsart in diese Themen involviert war, wird sie für sich beziffern können.

Des Weiteren unterscheiden sich die beiden Ansätze auch hinsichtlich ihrer bilanziellen Auswirkungen. 1.000 €, die das Unternehmen verlassen, sind natürlich 1.000 €, egal ob als Gehalt oder Beratungshonorar. Im Rechnungswesen wird aber nicht ohne Grund zwischen Ausgaben, Aufwand und Kosten unterschieden, da 1.000 €, je nachdem wie sie verbucht werden (können), auch einfach nur einen entsprechenden Mittelabfluss darstellen oder die Bilanz und somit den Unternehmenswert dabei entsprechend erhöhen können, Stichwort CAPEX/OPEX [7]. Die sogenannte Aktivierung von externem Beratungshonorar fällt dabei regelmäßig leichter, da Gehälter üblicherweise pauschal Betriebsausgaben und somit OPEX sind.

Vereinfacht gesagt, kostet ein angestellter und ein externer Softwareentwickler also nahezu das gleiche. Entscheidend für das eine oder andere Modell sind also insbesondere deren weitere Eigenschaften. Ob die Vorteile des Externen wie zum Beispiel Flexibilität, Spezialwissen und gegebenenfalls höher darstellbarer Unternehmenswert durch bessere Bilanzierungsmöglichkeiten die zugegebenermaßen auch vorhandenen Vorteile eines Angestellten aufwiegen, kommt, wie immer, auf die individuelle Situation und Zielsetzung an. Bei entsprechenden Vergleichen sollte also auch auf diese echten Unterscheidungskriterien eingegangen werden – die Kosten sind nahezu gleich.

Im zweiten Teil dieses Beitrags werden wir aus Sicht eines Technologieunternehmens aufzeigen, was bei der Vollkostenkalkulation zu beachten ist – und damit das geringe monetäre Delta von rund 15 % zwischen einem angestellten Softwareentwickler und seinem externen Pendant auflösen.

Fussnoten:

1.
Ein Einzelplatz im Coworking-Space ohne Computer ist beispielsweise ab 150 € pro Nutzer und Monat zu haben [8], lässt aber auch noch viele relevante Kostenpositionen außen vor. Eine etwas umfassendere Kalkulation der gemittelten Kosten für die Anmietung eigener Büroräume inklusive Besprechungsraum und Nebenkosten, aber noch ohne Computer, kommt bereits auf nahezu 500 € pro Monat und Arbeitsplatz [3]. Und die Sachkostenpauschale eines Arbeitsplatzes in der Bundesverwaltung wurde bereits 2010 inklusive IT-Kosten mit 1.030 € pro Monat ausgewiesen [9]. Dieser Betrag dürfte sich mittlerweile zwar einerseits noch weiter erhöht haben, umfasst andererseits aber auch Positionen, wie zum Beispiel Kapital- und Investitionskosten, welche nicht in jedem Fall anzusetzen sein dürften. Wir halten 1.000 € pro Monat und Arbeitsplatz inklusive IT-Kosten deshalb für kalkulatorisch angemessen. 

2.
Auch ein externer Berater erfordert natürlich ein gewisses Maß an »Betreuung« durch die Organisation und das Management des jeweiligen Kunden, beispielsweise für Beauftragung, Onboarding, etc. Wir orientieren uns hier am gesetzlichen Rahmen (Stichworte: Scheinselbständigkeit, Arbeitnehmerüberlassung), wonach externe Berater nicht in die Organisation des Kunden eingebunden sein dürfen, und lassen diese im Vergleich zu einem angestellten Mitarbeiter definitiv geringeren Kosten aus Vereinfachungsgründen außen vor. 

Effizienz oder Effektivität? Wenn die Softwareentwicklung optimiert werden soll, wird häufig an der falschen Stelle angesetzt. Die Lösung liegt mit Blick auf zwei Studien und unter Anwendung des Pareto-Prinzips auf der Hand. Die Produktivität der Softwareentwicklung kann so um das bis zu Fünffache gesteigert werden – allerdings nicht durch schnelleres Tippen …

Inhalt:

• Einleitung
• Effizienz – wie entwickelt wird
  – Multitasking
• Effektivität – was entwickelt wird
  – Lösungsansätze
• Fazit

Einleitung

Die Softwarekrise ist auch rund 50 Jahre nach ihrer offiziellen Feststellung noch nicht überstanden. Jede Softwareentwicklungseinheit steht vor der Herausforderung, dass es mehr Bedarf beziehungsweise Anforderungen als Entwicklungskapazität gibt. Um dem entgegenzuwirken, liegt der Fokus von entsprechenden Optimierungsversuchen häufig auf Produktivitäts- beziehungsweise Effizienzsteigerungsmaßnahmen. Salopp gesagt, wird versucht, durch “schnelleres Tippen” mehr Software in kürzerer Zeit entwickelt zu bekommen.

Dies funktioniert aus verschiedenen Gründen nicht. Einerseits wird bei Effizienzsteigerungsversuchen häufig an der falschen Stelle angesetzt und der echte Hebel in der Softwareentwicklung, die Effektivität, wird andererseits viel zu selten betrachtet.

Effizienz – wie entwickelt wird

Softwareentwicklung ist zu einem hohen Anteil eine geistig-kreative Tätigkeit. Natürlich muss auch ein Schriftsteller zügig schreiben können, der Fertigstellungstermin eines Romans ist aber nur zu einem geringen Anteil von der reinen Schreibgeschwindigkeit des Schriftstellers abhängig. Gleiches gilt für die Softwareentwicklung. Es gibt zwar noch wenige Studien hierzu, die bestätigen allerdings unsere Projekterfahrung. Demnach umfasst ein Großteil der gesamten Entwicklungszeit für eine einzelne Software-Funktion Wartezeit und nur ein geringer Anteil ist Arbeits- beziehungsweise eben “echte” Entwicklungszeit:

© Darstellung: Schwarze Consulting GmbH – © Daten: Kanban University: https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Die sogenannte Flow Efficiency, also die Dauer für die Entwicklung einer Funktion geteilt durch die reine Arbeitszeit, beträgt üblicherweise 15 %; Organisationen, die sich noch gar nicht mit dem Thema befasst haben, liegen häufig bei nur 1-2 % und am anderen Ende gibt es wenige Entwicklungseinheiten, die auf eine Flow Efficiency von bis zu 40 % kommen. Der Normalverteilung folgend, darf man hier aber guten Gewissens erstmal die üblichen 15 % ansetzen.

Der ABC-Analyse oder auch dem Pareto-Prinzip folgend, sollte man sich bei einer Wartezeit von 85 % natürlich zunächst um diesen großen Hebel kümmern. Bei entsprechenden Produktivitäts- beziehungsweise Effizienzsteigerungsmaßnahmen der Softwareentwicklung wird er aber unserer Erfahrung nach nahezu kategorisch ignoriert. Vermutlich weil die Wartezeiten schwerer zu greifen sind, als die eigentliche Arbeitsleistung. Dabei sind sie auch einer der Gründe, warum die Umsetzungsdauer von Entwicklungsvorhaben schwer zu schätzen ist, beziehungsweise entsprechende Schätzungen häufig daneben liegen: Wartezeiten sind kaum vorhersehbar, geschweige denn solide abschätzbar. Was ich zu entwickeln habe, kann ich als Entwickler sicherlich sehr gut mit etwas Erfahrung einschätzen. Aber wann ich wie lange auf was oder wen dabei zu warten habe, ist nicht deterministisch.

Selbst wenn man mit viel Aufwand die Entwicklungsgeschwindigkeit um 50 % erhöht bekäme, so hat man auf die übliche Flow Efficiency doch dann gerade mal 7,5 % an Umsetzungsdauer gewonnen1. Die Fertigstellung einer einzelnen Funktion wird durch “schnelleres Tippen” des Entwicklers also nur unwesentlich beschleunigt.

Und wenn man ehrlich ist, so wird in vielen Organisationen durch eine Vielzahl von Hürden für den Entwickler die Entwicklungsgeschwindigkeit sogar eher noch mutwillig reduziert. Als Beispiele seien hier die Team-übergreifend einheitlich zu verwendende IDE zu nennen, die den einzelnen Entwickler eher verlangsamt. Oder Internet-Proxys, die einen daran hindern, notwendige Entwicklungsbibliotheken zu beziehen, nicht vorhandene Admin-Rechte auf dem Entwicklungsrechner, quälende langsame Test-Suiten, für die niemand Zeit zum Aufräumen bekommt, und so weiter.

Nicht, dass das falsch verstanden wird. Es ist extrem wichtig, in die Entwicklungseffizienz durch vernünftiges Tooling, individuelle IDEs und schnelle Feedback-Zyklen zu investieren, um einem Entwickler eine optimale Arbeitsumgebung zur Verfügung stellen zu können und so insbesondere die Entwicklungsqualität zu erhöhen. Die Umsetzungsdauer eines Features wird dies aber, wie gezeigt, nicht signifikant reduzieren.

Multitasking

Ein Entwickler wechselt bei entsprechender Wartezeit natürlich zu einer anderen Aufgabe, zum Beispiel der Entwicklung eines zweiten Features:

© Schwarze Consulting GmbH

Dieses Task-Switching ist aber sowohl grundsätzlich als auch bei Entwicklungstätigkeiten im Besonderen ein Produktivitäts- und Qualitäts-Killer. Jeder, der schon mal versucht hat, eine Aufgabe zu erledigen, die eine gewisse Konzentration erfordert und dabei permanent unterbrochen wurde, sollte das leicht nachvollziehen können. Und bis ein Entwickler das mentale Modell einer umfangreichen Codebasis “in den Kopf geladen” hat, können auch schon mal Stunden vergehen, bevor eine Zeile verändert wird. Blöd, wenn er dann kurz vorher gestört wird. Es ist also extrem wichtig, ein Arbeitsumfeld für Entwickler zu schaffen, in dem sie durchaus mehrere Stunden ungestört sind.

Sind dann mehrere Entwicklungsaufgaben parallel in Bearbeitung, um die Wartezeit zu optimieren, kommt es häufig zu Situationen, in denen der Entwickler eigentlich an beiden Features gleichzeitig arbeiten müsste, was natürlich nicht geht. Somit entsteht an einer Stelle eine zusätzliche Wartezeit (⚠️) und die Umsetzungsdauer erhöht sich entweder beim einen (Entwicklungsdauer Feature 1 = 100 % + x) oder beim anderen Feature (Entwicklungsdauer Feature 2 = 100 % + y) entsprechend. Die Umsetzungdauer jedes einzelnen Features, welches parallel zu anderen entwickelt wird, verlängert sich durch Multitasking also.

Untersuchungen zeigen, dass ein Entwickler trotz dieser Task-Wechsel aber auch nur 25-50 % seiner Zeit pro Tag mit reinen Entwicklungstätigkeiten verbringt. Unter Annahme der üblichen Flow Efficiency von 15 % schafft ein Entwickler es also, an 2 bis 3 Features parallel zu entwickeln; mit entsprechenden Zeit- und Qualitätseinbußen. Also liegt auch unter Einsatz von Multitasking das angenommene Effizienzpotential durch “schnelleres Tippen” bei nur 18,75 % 2 und somit immer noch unter der Pareto-Schwelle.

Effizienz in der Softwareentwicklung ist also nicht der Heilsbringer, da ihr Hebel gering ist und ihre Optimierung, beispielsweise durch Multitasking auch negative Auswirkungen mit sich bringt.

Effektivität – was entwickelt wird

Die Effektivität, also die Frage, was beziehungsweise ob das Richtige entwickelt wird, ist bei der Optimierung von Softwareentwicklungsvorhaben unserer Erfahrung nach häufig nur von nachrangiger Bedeutung. Dabei werden nur 20 % der Anforderungen wirklich benötigt:

© Darstellung: Schwarze Consulting GmbH – © Daten: Universität Karlsruhe: https://ps.ipd.kit.edu/downloads/za_2007_schlanke_produktionsweisen_moderne_softwareentwicklung.pdf

Auch hier springt einen die ABC-Analyse oder das Pareto-Prinzip wieder geradezu an. Durch die richtige Auswahl dessen, was entwickelt wird, also über die Effektivität, lässt sich die Softwareentwicklung offensichtlich wesentlich leichter verbessern als über die Effizienz: der Hebel ist hier mit 80 % beim “Was” entwickelt wird viel höher als die oben weiter genannten 15 % beim “Wie”.

Zugegebenermaßen etwas polemisch formuliert, müsste eine Entwicklungseinheit, da bei 20% ja nur jedes fünfte umgesetzte Feature auch wirklich zum Einsatz kommt, kalkulatorisch auch “einfach” nur fünf Mal so groß sein, um die fehlende Effektivität zu kompensieren. Wir sind mit dem Vorschlag leider noch bei keinem Budgetverantwortlichen durch gekommen …

Bei Umsetzungen im Kundenauftrag ließe sich natürlich argumentieren, dass der Kunde doch alle Anforderungen bezahlt und damit doch wohl auch alle Anforderungen benötigt werden. Doch auch hier ist der Bedarf meist größer als die Entwicklungskapazität oder das Entwicklungsbudget. Und auch in diesem Fall stellt der Auftraggeber früher oder später fest, dass das eine oder andere Feature vielleicht doch nicht oder zumindest nicht so gebraucht wird, weshalb man auch hier drauf achten sollte, was entwickelt wird.

Weniger ist in der Softwareentwicklung also wirklich mehr, auch wenn es zunächst abwegig erscheint und abgedroschen klingen mag. Optimierungsversuche sollten hier also immer zuerst auf die Effektivität abzielen.

Lösungsansätze

Wie kann ich aber nun die Effektivität meiner Softwareentwicklung erhöhen, also dafür sorgen, dass möglichst viel von dem umgesetzt wird, was auch wirklich benötigt wird und möglichst wenig von dem, was nicht wirklich benötigt wird?

Wir erleben immer wieder Product-Backlogs, die voll von uralten Features sind. Wissend, dass 80 % davon nicht wirklich gebraucht werden, kann man also guten Gewissens davon ausgehen, dass die wichtigen Features schon umgesetzt wurden und die, die eine gewisse Zeit lang nicht zur Umsetzung kamen, auch nicht mehr gebraucht werden. Trotzdem müssen diese Features dann häufig umgesetzt werden, wodurch knappe Entwicklungskapazität unnötig gebunden wird. Effektive Softwareentwicklung ist keine “Supermarktkasse”, wo jeder früher oder später dran kommt. Um effektiver zu werden, müssen die Anforderungen sich jeden Tag aufs Neue hinsichtlich ihrer Priorität beweisen; Anforderungen, die nicht wichtig genug sind, sollten auch nicht “dran kommen”, wenn man mehr (des Richtigen) aus der Entwicklung bekommen möchte.

Anders herum erleben wir auch immer wieder, dass die Priorisierung von Features darüber erfolgt, welcher Anforderer “am lautesten schreit”. Wenn 80 % der Features aber nicht benötigt werden, wird so wiederum wertvolle, da knappe Entwicklungskapazität für unnötige Themen verschwendet, weil der, der am lautesten schreit, noch lange nicht der wichtigste Anforderer ist. Gibt man denen nach, entsteht natürlich der Eindruck, dass aus einer Entwicklungseinheit nicht genug heraus kommt, da eben nicht genug des Richtigen heraus kommt. So lange die Entwicklungseinheit sich selbst die Aufgaben priorisiert, wird sie immer Teil des Problems sein. In diesem Fall ist es genau wie an einer Supermarktkasse: Wenn ich vorgelassen werden möchte, kann das nicht der Mitarbeiter an der Kasse, also die Entwicklungseinheit entscheiden, sondern ich muss der Reihe nach alle vor mir Stehenden fragen beziehungsweise davon überzeugen, dass mein Anliegen dringender ist.

Wichtig ist in solchen Fällen, dass die üblicherweise vielen verschiedenen Stakeholder der Softwareentwicklung das Problem unter sich lösen. Hierzu haben wir schon erfolgreich unterschiedliche Ansätze, üblicherweise Gremien-orientiert in verschiedenen Organisationen implementiert. Alternativ wird es durch einen entsprechend “starken” Product Owner erledigt:

© Scrum.Org: https://www.scrum.org/resources/blog/evolution-product-owner

Die Rolle des Product Owners ist zwar mittlerweile in vielen Organisationen, die sich mit Softwareentwicklung beschäftigen, besetzt. Unserer Erfahrung nach aber noch eher selten im Sinne eines »Unternehmers im Unternehmen« (“Entrepreneur”), der auch alleine und vollumfänglich über die Roadmap und Features “seines” Produktes entscheiden kann. Dabei ist eine seiner Hauptaufgaben, “Nein” zu den meisten Anforderungen zu sagen und das Entwicklungsteam so effektiv und produktiv entwickeln zu lasssen. Alle anderen der oben gezeigten Ausprägungen der Rolle Product Owner werden üblicherweise einen konsens-orientierten Ansatz mit ihren Stakeholdern zur Priorisierung finden müssen. Wobei auch einem “starken” Product Owner dieser Weg durchaus angeraten sein kann.

Fazit

Eine effiziente Softwareentwicklung ist heutzutage ein Hygienefaktor. Über die Effizienz lässt sich die Produktivität in der Entwicklung, wie wir gezeigt haben, mit unter 20 % auch nur begrenzt steigern. Wenn das Thema Effizienz in der Softwareentwicklung angegangen wird, empfehlen wir, Wartezeiten zu reduzieren, da diese üblicherweise den Großteil der Entwicklungszeit eines Features ausmachen.

Wer wirklich mehr aus seiner Softwareentwicklungseinheit heraus bekommen möchte, sollte tatsächlich weniger entwicklen, nämlich weniger der nicht benötigten Features. Über die Effektivität lässt sich die Produktivität in der Entwicklung um das bis zu Fünffache steigern! Dann ist auch wieder ausreichend Kapazität für die wichtigen Features vorhanden. Hierzu wird jemand in verantwortlicher Position gebraucht, der “Nein” sagen kann – beispielsweise ein entsprechend “starker”, also befähigter und ermächtigter Product Owner.

Fussnoten:

1. 15 % normale Flow Efficiency beziehungsweise Entwicklungszeit * 50 % angenommene Optimierung = 7,5 % optimierte Entwicklungszeit und somit Reduktion der gesamten Umsetzungsdauer. 
2. Der Mittelwert der Zeit, die ein Entwickler pro Tag mit reiner Entwicklung verbringt von 25-50 % ist 37,5 %. Die Annahme im voran gegangenen Beispiel bei der Entwicklung eines Features war, dass 50 % der reinen Entwicklungszeit optimierbar wären. Bei Multitasking somit also 50 % von 37,5 % = 18,75 %. 

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Unser Blogbeitrag »Die Wachstumsrate von Software« wurde als Fachartikel in der Fachzeitschrift OBJEKTspektrum veröffentlicht.

Die Fachzeitschrift OBJEKTspektrum »liefert zuverlässige Hintergründe, Trends und Erfahrungen zu Software-Management, -Architektur und -Engineering«. Unser Blogbeitrag »Die Wachstumsrate von Software« fand Anklang bei der Redaktion der OBJEKTspektrum und wurde in einer erweiterten Fassung in Ausgabe 1/2019 veröffentlicht.

Interessierte können sich den ganzen Artikel hier herunterladen.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Inhalt:

• Bleeding-edge for the Enterprise
• Workshops
  • From Developer to Architect
  • Coaching the Team System
• Keynotes
  • Developers as a Malware Distribution Vehicle
  • A Brief, Opinionated History of the API
• Vorträge
  • Software Updates in an Orchestrated World
  • WebAssembly 101
  • Understanding Code Performance in Production
  • From Software Development to Machine Learning
  • Skype’s Journey From P2P
  • Explaining Artificial Intelligence to Schoolchildren
  • The Story of Teams, Autonomy, and Servant Leadership
  • AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web
  • Breaking Codes, Designing Jets and Building Teams
  • Empowering Agile Self-Organized Teams With Design Thinking
  • Software Is Eating the World, ML Is Going to Eat Software
• Einschätzung

Bleeding-edge for the Enterprise

Nach der QCon 2015 in San Francisco stand dieses Jahr New York für uns auf der Agenda. Mit dem Veranstaltungsort direkt am Times Square war die Konferenz im wahrsten Sinne des Wortes am Puls der Zeit. Die Veranstaltung ist »designed for senior software engineering leaders« und bot den über 900 Teilnehmern 117 Vorträge von 143 Rednern aus folgenden Themenbereichen:

© C4Media Inc | InfoQ.com

Ob nun jedes Thema oder jeder der genannten Themenbereiche wirklich »bleeding-edge« ist, hängt natürlich immer auch von der eigenen Positionierung innerhalb der »Technology Adaption Curve« ab. Unserer Einschätzung nach ist die QCon schon sehr nah am Puls der Zeit und das nicht nur geografisch. Tech Leads und ähnliche Rollen aus den Entwicklungsabteilungen von führenden Firmen im Software Engingeering wie Facebook, Netflix & Co. berichten hier über das, was jeweils wirklich schon im Einsatz ist. Ein schönes Beispiel hierzu ist das Thema Machine Learning. Während unserer Einschätzung nach die meisten Firmen, wenn überhaupt, noch dabei sind, das Thema zu verstehen, im besten Fall damit herum experimentieren, zeigte Facebook auf der Konferenz, wie sie es schon zur konkreten Produktivitätssteigerung in der eigenen Entwicklungsabteilung und zur Optimierung des Cache-Managements in der Infrastruktur einsetzen – Use Cases die wir so, zumindest vorher, noch nicht gesehen hatten.

Waren Microservices 2015 als sogenannte »Innovators« in QCons »Technology Adaption Curve« noch beherrschendes Thema, so befinden sie sich nun in der »Early Majority« (siehe Grafik oben). Folglich gab es zwar noch einen Track zum Thema, hier lag der Fokus der Vorträge dann aber auch auf sehr konkreten Anwendungs- und Betriebsthemen derselben.

Die beherrschenden diesjährigen Themenbereiche waren entsprechend auch wieder aus den Bereichen »Innovators« und »Early Adopters«, insbesondere Serverless, Chaos Engineering und Machine Learning sowie Blockchain, Rust, Web Assembly und Software Ethics. Wobei die Einstufung des letzten Themenbereichs innerhalb »Innovators« uns dann doch verwundert hat, da wir Ethik als relevante Dimension der Leistungsbeurteilung beispielsweise nun schon seit über 10 Jahren propagieren und nicht unbedingt als Innovation sehen würden.

Workshops

Die ersten zwei Tage der Konferenz waren ausschließlich Workshops gewidmet. Themen reichten von Serverless über die Programmiersprache Go und Python-basierte AI bis zu Microservices »in Aktion«. Neben diesen eher technologischen Themen gab es auch wieder Workshops zu den »weicheren« Aspekten rund um Softwareentwicklung.

From Developer to Architect

In diesem Workshop wurde aufgezeigt, was einen Softwarearchitekten von einem Softwareentwickler unterscheidet, beziehungsweise was die Rolle des Architekten an Aufgaben mit sich bringt. Die Wichtigkeit dieser Rolle in Softwareentwicklungsvorhaben haben wir ja bereits an anderer Stelle aufgezeigt.

Zunächst wurden hier die organisatorischen und kommunikativen Aspekte der Architektenrolle herausgestellt. Dass ein Architekt viel kommunizieren muss, mag einleuchten, bedeutet aber andererseits auch, dass er viel Zeit in Besprechungen verbringt. Interessant ist hier die Analogie, dass Architektur eine Geschichte ist, die erzählt werden muss. Wer das als Entwickler nicht mag, sollte sich eventuell überlegen, ob er wirklich Architekt werden möchte, beziehungsweise weiß die Arbeit, die der Architekt dem Entwickler damit abnimmt, dann vielleicht auch ganz anders zu schätzen.

Mit den organisatorischen Aspekten sind dann häufig auch Budgetfragen verbunden, die ein Architekt zu beantworten hat. Und wo es um Geld geht, wird es schnell politisch, weshalb ein Architekt auch wissen muss, wie er welche Botschaft wann an wen sendet. Hier kann Ben Thompsons Social/Communication Map helfen.

Auch wurde angesprochen, dass die Entwicklung zum Architekten in der Praxis ja (leider) häufig über Versuch und Irrtum erfolgt. Dass Architekten in ihrer Laufbahn aufgrund der tendenziell langläufigen Natur ihrer Arbeit häufig nur wenige Architekturen von Anfang bis Ende bearbeiten können, erschwert dies zusätzlich. Wobei der Referent dabei auch die interessante Frage stellte, was denn eigentlich die Definition-of-Done einer Architektur ist? Neal Fords Architektur Katas wurden als ein Element genannt, um Architekturentwicklung gefahrlos üben zu können. Denn ein guter Architekt wird man, in dem man an Architekturen arbeitet:

»How do we get great designers? Great designers design, of course.« –Fred Brooks

Ein weiterer Teil des Workshops war der Technologieauswahl gewidmet. Auch wenn Architektur nicht gleich Technologie ist, so ist die Technologieauswahl doch häufig Architektenaufgabe. Der Architekt sollte hierbei aber die eigentlichen Ziele nicht aus dem Auge verlieren. So ist beispielsweise die Testabdeckung in der Regel wichtiger, als welches Testing-Framework schlussendlich zum Einsatz kommt. Da Technologiefragen gerade unter Entwicklern gerne auch ideologisch geführt werden, ein guter Tipp vom Referenten:

»Avoid resume-driven decisions!« –Nathaniel T. Schutta

Üblicherweise verantwortet ein Architekt die sogenannten nicht-funktionalen Anforderungen, weshalb ein weiterer Block auch diesen sich häufig widersprechenden Attributen einer Software gewidmet war, wie zum Beispiel:

• Wartbarkeit
• Skalierbarkeit
• Verlässlichkeit
• Sicherheit
• Ausrollbarkeit
• Einfachheit
• Nutzbarkeit
• Kompatibilität
• Fehlertoleranz
• Modularität
• …

Aus Sicht des Referenten sollte ein Architekt hier aber besser von Qualitätsmerkmalen reden. Denn welcher Kunde zahlt schon gerne für etwas, das keine Funktion erfüllt und was er üblicherweise nicht direkt sieht?

Da Architekturentscheidungen getroffen werden, ob man es will oder nicht (»Accidental Architecture«), ist es wichtig, die Rolle des Architekten zu klären. Die besten Architekturen entwickeln sich nach aktuellem Kenntnisstand evolutionär (»Evolutionary Architectures«) durch

• Nutzung von Feature Toggles
• sowie hypothesengestützte Entwicklung,
• Einsatz von Fitnessfunktionen
• und Chaos Engineering.

In Anlehnung an Winstons Churchills Ausspruch zur Demokratie gab der Referent zum Thema Prozesse zum Abschluss noch ein Zitat mit Augenzwinkern auf den Weg:

»Agile is the worst form of software development, except all other.« –Nathaniel T. Schutta

Insgesamt ein solider Grundlagen-Workshop zur Rolle des Architekten, wenn auch nicht unbedingt »bleeding-edge«. Ein wenig mehr Bezug zu aktuellen Fragestellungen der Softwarearchitektur, wie beispielsweise Architektur im Kontext agiler Softwareentwicklung hätte den Workshop noch abgerundet.

Coaching the Team System

Teams verändern sich. Hilfestellungen hierzu bot dieser Workshop. Wurde früher versucht, Teams wie Systeme möglichst stabil zu halten (»Never change a running/winning…«), so setzt sich immer mehr die Erkenntnis durch, dass wir damit eher das Gegenteil erreichen, da wir so im Moment der Veränderung schlecht vorbereitet sind: Wie sollen wir gut in etwas sein, was wir nicht regelmäßig praktizieren?

»Teams change. Better get good at it.« –Heidi Helfand

Die Referentin zeigte zunächst auf, dass bereits wenn eine Person ein Team verlässt oder hinzu kommt, eine neue Teamsituation entsteht, auf die wir eingehen müssen. Veränderungen passieren dabei auch noch auf verschiedenen Ebenen:

• Person
• Team
• Gilde, Stamm, Tribe – Gruppierungen einzelner Rollen, beispielsweise »alle Entwickler«
• Abteilung
• Unternehmen

Außerdem folgen auch Veränderungen einem Zyklus. Dreht es sich während der Entstehung eines Teams beispielsweise eher um Fragen des Onboardings neuer Mitarbeiter, so stehen heranwachsende Teams vor anderen Herausforderungen. Hier muss dann zum Beispiel mit kulturellen Veränderungen umgegangen werden, wenn aus eher chaotischen Startups Hierarchien entwachsen. Reife und stabile Teams benötigen wiederum oftmals eher einen Impuls, um wieder Energie freizusetzen beziehungsweise Veränderungen anzustoßen. Zu jeder dieser Coaching-Herausforderungen gab die Referentin entsprechende Tools mit auf den Weg, beispielsweise die »Market of Skills«-Aktivität, beim Onboarding neuer Mitarbeiter oder die »First-Team«-Aktivität, wenn kulturelle Aspekte geteilt werden sollen.

Googles Projekt Aristotels hat dabei eindrucksvoll gezeigt, dass dies nichts Esoterisches ist, sondern dazu dient, das, was erfolgreiche Teams ausmacht, herzustellen: »psychologische Stabilität«.

Bleibt die Frage, wer im Unternehmen dann eigentlich diese wichtige Rolle des Coaches übernimmt. Die Rolle Teamleitung als »klassische« erste Anlaufstelle für diese Fragen sehen wir hierzu insbesondere in agilen Teams immer häufiger gar nicht mehr genug »auf dem Spielfeld«. Gleichzeitig reduzieren Unternehmen die Rolle des Scrum Masters häufig nach einiger Zeit zum Teil drastisch, da »Scrum ja dann eingeführt ist«. Wir haben schon erlebt, dass ein Scrum Master beziehungsweise agiler Coach für 10 und mehr Teams zuständig war. Idealerweise verfügt jedes Team über diese notwendigen Teamentwicklungs-Skills, aber auch dieser Zustand muss erfahrungsgemäß zunächst hergestellt werden. Und dann ändert sich das Team wieder. Booking.com hat im Vortrag »The Story of Teams, Autonomy, and Servant Leadership« vom Donnerstag (siehe unten) interessanten Einblick in ihren Ansatz dazu gegeben.

Keynotes

Jeder der drei folgenden Konferenztage begann jeweils mit einer Keynote, welche durch Themenwahl und Vortragenden auch immer zum Nachdenken anregen sollte.

Developers as a Malware Distribution Vehicle

Ein »guter« Softwareentwickler vereint bekanntermaßen die drei Eigenschaften Faulheit, Ungeduld und Überheblichkeit. In diesem Vortrag wurde aufgezeigt, dass gerade diese Kombination ihn aber auch besonders empfänglich für Hacker-Angiffe macht.

So hat XcodeGhost in 2015 beispielsweise über 4.000 Apps infiziert und bis zu 1,4 Millionen Opfer pro Tag geschädigt. Dabei wurde von Unbekannten eine infizierte Version von Apples IDE XCode hinter Chinas Great Firewall ausgerollt. Diese hatte prominente Apps wie zum Beispiel WeChat durch einen veränderten Compiler mit Schadcode versehen, wodurch die betroffenden Apps gleich mehrere Angriffsvektoren aufwiesen (Remote Control, Datendiebstahl und mehr). Der Referent brachte hier noch eine Vielzahl weiterer Beispiele, von versehentlich auf Github publizierten Zugangsdaten des Fahrdienstleisters Uber bis zu einem Phishing-Angriff auf einen Entwickler der Financial Times. Im ersteren Fall gelangten Millionen Daten von Millionen Fahrgästen und Fahrern von Uber an die Öffentlichkeit. Im letzteren Fall wurden zwar nur kurzzeitig falsche Meldungen über Twitter veröffentlicht, ein ähnlicher Fall bei der AP brachte aber beispielsweise den Dow Jones innerhalb von Minuten um 1 % nach unten. Jedes Mal waren Entwickler das Einfallstor für die Hacker. Salesforce.com führte nach Angaben des Referenten einen internen Phishing-Test durch und Entwickler hatten dabei die zweithöchste Klickrate.

Das Schlimme hieran: Compiler-Hacks wie der geschilderte XCodeGhost sind schon mindestens seit dem sogenannten »Ken Thompson Hack« von 1984 bekannt.

Open-Source Software hat dabei noch einen vermeintlich sicheren Status, da der Quellcode ja öffentlich einsehbar und somit nur schwerlich kompromittierbar ist. Aber wer weiß schon, ob das entsprechende npm-Package auch dem Sourcecode auf Github entspricht? Vergangenes Jahr wurden auf diesem Wege beispielsweise 39 infizierte Packages über zwei Wochen via npm verteilt. Und das zieht sich quer durch alle Technologien. So wurden gerade vergangenen Monat 17 infizierte Docker-Images offline genommen. Und Rubys Paketsystem RubyGem hatte in 2016 sein entsprechendes Sicherheits-Debakel. Das lokale Kompilieren des sauberen Quellcodes könnte hier helfen. Das machen aber nur die Wenigsten. Und dann war da ja noch die Sache mit dem Compiler-Hack…

»You cannot trust code which you do not totally control.« –Guy Podjarny

Der Referent konnte verschiedene Gründe aufzeigen, warum gerade Entwickler dazu neigen, Entscheidungen zu treffen, die negative Auswirkungen auf die Sicherheit eines Systems haben:

• Fokus auf Funktion: Sicherheit wird als Einschränkung wahrgenommen.
• Kognitive Beschränkung: Facebook hat seinen initialen Slogan »Move fast and break things« nicht ohne Grund zu »Move fast with a stable infrastructure« geändert.
• Einerseits fehlendes Wissen: Nicht jeder Entwickler versteht alle Sicherheitimplikationen seiner Arbeit.
• Andererseits fühlen Entwickler sich häufig zu sicher (siehe auch die eingangs erwähnten Eigenschaften eines »guten« Entwicklers) und sind damit beispielsweise dann auch schwerer zu schulen.
• »Das passiert mir doch nicht«-Mentalität, dabei passieren Sicherheitsvorfälle jedem.

Als mögliche Gegenmaßnahmen wurde Folgendes empfohlen:

• Systematisches Lernen aus vergangenen Fehlern
• Sicherheitskontrollen automatisieren
• »Make it easy to be secure«
• Zutritt »wie die Großen« managen, beispielsweise
  • Googles BeyondCorp
  • Microsofts Priviliged Access Workstations
  • Netflix’ BLESS

Die Keynote war ein gelungener Einstieg in den ersten Konferenztag und durchaus ein Augenöffner für gewisse Sicherheitsthemen.

A Brief, Opinionated History of the API

In der zweiten Keynote nahm sich Joshua Bloch, Chief Java Architect von Google, vormals Distinguished Engineer für Sun Microsystems und Autor unter anderem von Effective Java, die Geschichte der API (Application Programming Interface) vor und brachte dabei Erstaunliches zutage.

Bereits 1948 erwähnten Goldstine und von Neuman erstmals eine »Subroutine Library« in ihrer theoretischen (!) Abhandlung über das Programmieren eines sogenannten »Electronic Computing Instruments«. Wilkes hat dann 1951 mit Wheeler und Gill Programmbibliotheken mit dem ersten Text zur Computerprogrammierung überhaupt »Preparation of Programs for Electronic Digital Computers« praktisch eingeführt und wurde unter anderem dafür 1967 mit dem Turing Award ausgezeichnet. Schon damals stellten sie fest:

»Documenting [APIs] is hard.«

Außerdem sollten Programmbibliotheken schon damals Komplexität vor dem Nutzer verbergen. APIs sind natürlich keine Programmbibliotheken, sondern heute losgelöst von ihnen zu sehen. Eine Programmbibliothek hat aber eine entsprechende Schnittstelle (Interface), um die Applikation programmatisch einzubinden. Somit darf man die Programmbibliothek durchaus als Vorläufer der API ansehen. Selbiger Begriff wurde dann erstmals ab 1968 genutzt.

Der Wert einer (guten) API liegt darin, dass die Implementierung geändert werden kann, ohne dass der Nutzer davon etwas merkt. Der Lebenszyklus einer API ist also losgelöst von der Implementierung: »Write once, run anywhere«. Daraus ergibt sich auch der folgende »Test«, ob eine Schnittstelle als API zu verstehen ist oder nicht:

• Es wird ein Set an Operationen bereitgestellt, welche durch ihre Ein- und Ausgaben definiert sind.
• Re-Implementierung ohne Beeinträchtigung des Nutzers wird unterstützt.

Da das vielleicht etwas abstrakt ist, brachte der Referent dann historische Beispiele für entsprechende APIs, die vielleicht nicht jeder bisher auch als solche verstanden hat:

Viele der oben genannten Beispiele sind heute noch im Einsatz. Der Hayes AT Befehlssatz für Modems findet sich heute noch in fast allen Handys. Und die Standardisierung und Re-Implementierungsmöglichkeit des IBM PCs in Kombination mit MS-DOS haben die Ära der PCs der 1980er Jahre begründet, von der wir auch heute noch zehren. WINE ist wiederum ein schönes Beispiel für eine Re-Implementierung einer API ohne Beeinträchtigung des Nutzers, in dem Fall der Windows-32-API auf unixoiden Systemen. Genauso bilden die C-Standard-Bibliothek und die Unix System Calls das Fundament unserer heutigen digitalen Welt, findet sich doch dank Android ein (freies) Unix in mittlerweile Milliarden von Geräten:

»APIs are the glue that connect our digital universe.« –Joshua Bloch

Bislang war die Re-Implementierung von APIs rechtlich unproblematisch. Durch den Rechtsstreit von Oracle mit Google ändert sich die Situation zumindest in den USA derzeit. Oracle wirft Google vor, dass deren Re-Implementierung der Java Standard Edition Bibliothek für das Android Betriebssystem Oracles Copyright und Patentrechte verletze. Der Prozess läuft bereits seit 2012 und durch mehrere Instanzen. Der aktuellste Entscheid spricht sich für Oracle aus, wodurch APIs derzeit in den USA quasi Copyrightschutz besitzen und nicht ohne Zustimmung des Autors frei re-implementiert werden sollten. Sollte sich hieran nichts mehr ändern, wird unserem digitalen Universum das zusammenhaltende Element entzogen.

Der Referent war in den Gerichtsprozessen als Gutachter tätig und hat sich auch in diesem Vortrag entsprechend für die weiterhin freie Implementierbarkeit von APIs ausgesprochen, weshalb er den Vortrag auch als »opinionated« benannt hat.

Vorträge

Software Updates in an Orchestrated World

Dieser Vortrag lief innerhalb der »Sponsored Tracks«, wurde also von einem Produkthersteller und Sponsor der QCon, in diesem Fall der Firma JFrog durchgeführt.

Der Referent griff den für uns auf der Konferenz durchgängig erkennbaren Faden auf, dass es sicherer ist, oft und schnell zu releasen, als die Systeme stabil zu halten. Aufhänger hierfür war die zunehmende Komplexität der Systeme, die wir entwickeln. Insbesondere, da der Großteil eines Systems üblicherweise aus externer Software besteht, wie wir hier am Beispiel der freien, webbasierten Projektmanagementsoftware Redmine exemplarisch nachgestellt haben:

Die eigentliche Anwendung ist hier mit 200.000 Codezeilen beziehungsweise 1 % des Gesamtumfangs nur die Spitze des Eisbergs. 99 % der Anwendung sind Fremdcode, der aber auch verwaltet und insbesondere aktuell gehalten werden will. Die Abhängigkeiten machen die Situation dabei besonders brisant: löst man die rund 1.000 Abhängigkeiten von Kubernetes auf, so wächst allein diese Software schon auf stolze 35 Millionen Codezeilen an, wird also größer als das Betriebssystem.

Bei den exemplarischen 1.580 Abhängigkeiten des oben gezeigten Beispielsystems wäre man 4 Jahre mit Updates beschäftigt, würde man nur eine Abhängigkeit pro Tag aktualisieren. Natürlich bündelt man das in der Regel analog zu Microsofts Patchday. Trotzdem muss der gesamte Softwarestack nach Updates entsprechend getestet werden, was in der Regel einen Großteil des Aufwands ausmacht.

Artefakt-Repositories wie Sonatypes Nexus und JFrogs Artifactory helfen bei der Verwaltung dieser Vielzahl von Abhängigkeiten und somit letztlich bei der Fragestellung, wie man den Überblick über einen komplexen Softwarestack von tausenden von (Open Source) Systemen heutzutage behält. Dazu kommt jedoch noch die zunehmende Komplexität des Bereichs Cybersecurity, schön dargestellt anhand Henry Jiangs »Map of Cybersecurity Domains«. Hier wird erkennbar, dass es nicht mehr nur mit Updates der Fremdsoftware alleine getan ist. Risk-Management, Sourcecode Scans, Vulnerability Checks, Architectural Fit und so weiter wollen und müssen für den Fremcode ebenso bedacht sein:

© Henry Jiang | https://www.linkedin.com/pulse/map-cybersecurity-domains-version-20-henry-jiang-ciso-cissp

Die Produkthersteller erweitern ihre Portfolios natürlich entsprechend. So bietet JFrog beispielsweise mittlerweile auch Security Scans der Artefakte an. Der bisherige Platzhirsch Nexus wird dabei langsam von Artifactory überholt:

Der Vortrag hat deutlich gemacht, dass das Lifecycle-Management immer wichtiger, aber auch immer aufwändiger wird.

WebAssembly 101

WebAssembly könnte die Art und Weise, wie wir »Web Apps« schreiben, revolutionieren. Der Vortrag gab dem Namen (»101«) folgend einen guten Einstieg in das Thema.

WebAssembly ist ein binärer Befehlssatz, also eine Art Maschinensprache. Der Befehlssatz gilt allerdings nicht für einen speziellen Prozessor, sondern für eine virtuelle Maschine, welche von einer Arbeitsgruppe des World Wide Web Consortium (kurz W3C), dem Gremium zur Standardisierung der Techniken im World Wide Web, verabschiedet wird. Dadurch ist diese virtuelle Maschine auch bereits in allen modernen Browsern vorhanden, wodurch diese zusätzlich zu JavaScript eine weitere Laufzeitumgebung erhalten.

Da es in der Geschichte des Webs schon ähnliche Versuche gab, von Java Applets über Silverlight und Flash bis zu ASM.js und natürlich auch JavaScript, ist eine Abgrenzung hilfreich:

• WebAssembly ist keine Programmiersprache und kein neuer Browser;
  – es soll weder JavaScript ablösen, noch ist es so etwas wie Flash oder Java Applets.
• Ohne einen entsprechenden Host funktioniert die Technologie nicht,
  – wobei der Host nicht auf das Web beschränkt ist: alles kann ein WebAssembly Host sein.
• WebAssembly ist bislang noch im MVP-Status und dadurch
  – weder multi-threaded, was sich mit Web Workern aber umgehen lässt,
  – noch garbage-collected, was erklärt, warum Java noch nicht zu WebAssembly kompilieren kann.

Aufgrund der Eigenschaften von WebAssembly, wie zum Beispiel Geschwindigkeit, Portabilität, Effizienz und Sicherheit, sind Anwendungsfälle insbesondere im Umfeld Mobile, IoT sowie grundsätzlicher bei leistungsstarken Web-Anwendungen zu sehen.

Ziel ist dabei nicht, dass direkt in WebAssembly programmiert wird, da es sich wirklich um Binärcode handelt:

20 00

42 00

51

04 7e

42 01

05

20 00

20 00

42 01

7d

10 00

7e

0b

Es gibt zwar auch eine textuelle Entsprechung zu dem oben gezeigten Binärcode, also quasi Assemblercode, aber auch darin wollen wir heute nicht mehr wirklich direkt programmieren:

get_local 0

i64.const 0

i64.eq

if i64

    i64.const 1

else

    get_local 0

    get_local 0

    i64.const 1

    i64.sub

    call 0

    i64.mul

end

Ziel ist vielmehr, dass die gängigen Compiler neben den Prozessorarchitekturen, für die sie sowieso schon kompilieren können, also beispielsweise ARM32 oder x86-64 zusätzlich auch für WebAssembly kompilieren können. Für C/C++ und Rust sind bereits entsprechende Kompiler vorhanden. Das folgende C-Programm wurde beispielsweise entsprechend für WebAssembly kompiliert, um den voran gezeigten Binär- beziehungsweise Assemblercode zu erhalten:

int factorial(int n) {

  if (n == 0)

    return 1;

  else

    return n * factorial(n-1);

}

Der Ablauf, um ein Programm in WebAssembly zu erstellen und nutzen ist somit wie folgt:

1. Schreiben oder portieren eines Programms in einer Programmiersprache, welche WebAssembly unterstützt – derzeit C/C++, Rust und Go seit Version 1.11 zumindest experimentell.
2. Entsprechendes Kompilieren des Programms nach WebAssembly (WASM).
3. Das Kompilat wird dann über einen entsprechenden Webserver, der WebAssembly unterstützt, den sogenannten Host, ausgespielt
4. und kann dann, wie eine Webseite, von einem Browser, der WebAssembly unterstützt (Chrome, Edge, Firefox und WebKit/Safari), abgerufen werden.

Der Klassiker »helloWorld.c«

#include <stdio.h>

int main(int argc, char ** argv) {

  printf(„Hello, world!\n“);

}

kompiliert nach WebAssembly sieht als statische Seite im Browser natürlich noch unspektakulär aus:

Der in C geschriebene Editor VIM wurde aber auch schon erfolgreich nach WebAssembly kompiliert und ist darüber im Webbrowser lauffähig, was zeigt, welches Potential in der Technologie steckt:

Die Codebasis von VIM ist über 25 Jahre alt und umfasst mehr als 750.000 Zeilen, wurde aber in weniger als einer Woche von einem Entwickler nach WebAssembly portiert – inklusive Erlernen des notwendigen Toolings.

Im Vortrag »AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web« vom Donnerstag (siehe unten) gibt es weitere Details zu einem noch größeren Portierungsvorhaben. Die Spiele-Engine Unity ist wohl auch schon entsprechend portiert, »Tanks« lässt sich als WebAssembly-Demo zumindest schon im Browser spielen. Vielleicht ergibt sich so auch eine Lösung für das Cobol-Problem? Wir sind gespannt, ob und wann die ersten Cobol-Compiler WASM erzeugen können…

Understanding Code Performance in Production

Dieser Vortrag innerhalb der »Sponsored Tracks«, wurde von der Firma AppDynamics durchgeführt.

Produktive Umgebungen sind häufig anders als Entwicklungsumgebungen, da beispielsweise nicht jeder Entwickler auch zwangsläufig Zugang zu den entsprechenden Produktivsystemen seiner Applikation bekommt. Gleichzeitig verlagern sich die Erwartungen an den Betrieb von Applikationen durch Ansätze wie DevOps und You-Build-it-You-Run-it in Richtung Entwicklung. Hier kann sogenanntes Application Performance Monitoring dem Entwickler wichtige Informationen über das Verhalten seiner Software in Produktion liefern. Üblicherweise wird dabei bereits zur Entwicklungszeit eine entsprechende Software in die zu überwachende Applikation integriert, häufig in Form eines Agenten. Diese benötigen natürlich auch Ressourcen, weshalb sie mit bis zu 2 % Performance zu kalkulieren sind.

Am Markt haben sich mehrere Hersteller und Lösungen etabliert. AppDynamics ist dabei in Gartners Magic Quadrant für Application Performance Monitoring im Leaders-Quadranten eingestuft. Darüber hinaus war der Vortrag weitestgehend eine Produktvorführung.

From Software Development to Machine Learning

Bei diesem Vortrag handelte es sich um den Erfahrungsbericht der Transformation eines klassischen PHP-Software-Engineering-Teams hin zu Machine Learning aus Sicht der verantwortlichen Managerin. Der vorliegende Fall war sicherlich ein Extrembeispiel, da das Unternehmen sein Produktportfolio komplett umstellen wollte und die Entwicklung dementsprechend ebenso radikal umgestellt werden musste. Die Referentin hat das Unterfangen nicht ohne Grund mit einer Organtransplantation verglichen.

Die Transformation geschah dabei auf verschiedenen Ebenen:

• Individuum
• Team
• Unternehmen

Auf der Ebene des Individuums musste beispielsweise mit Python eine neue Technologie gelernt werden. Das mag sich zunächst nur nach einer weiteren Programmiersprache anhören, hat aber auch »soziale« Aspekte, da der Senioritätsgrad der Mitarbeiter damit quasi über Nacht abgestuft wurde, weil beispielsweise der vorherige PHP Senior Web Developer nun auf einmal Python Junior Engineer war.

Auf Team-Ebene muss man sich mit geänderten und ganz neuen Rollen auseinandersetzen. Aus einem Web Developer muss ein Machine Learning Engineer werden und aus einem Softwarearchitekt ein Data-Architekt. Ganz neu ins Spiel kommt der Data Scientist, nach Aussage der Referentin eine derzeit viel zu strapazierte Rolle, für die es bislang auch noch keine universelle Definition gibt. Außerdem können ihrer Meinung nach die wenigsten davon auf dem Level eines Software-Engineers entwickeln, da sie sich meist aus dem mathematisch-akademischen Bereich rekrutieren und damit zwar vielleicht gut in Algorithmen sind, aber nicht zwangsläufig wissen, wie man große, langlebige Systeme für den Produktiveinsatz entwickelt.

Aus eigener Projekterfahrung wissen wir, dass die Umstellung eines Teams auf eine neue Technologie zwar machbar ist, eine Organisation aber durchaus einige Jahre beschäftigen kann.

Wer sich selbst tiefer in das Thema Machine Learning einarbeiten möchte, findet hier eine gute Übersicht an Kursen.

Skype’s Journey From P2P

Dieser Vortrag zeigte Skypes Wandel von einer (»der«) P2P-Architektur hin zu einem Server- und Service-basierten Ansatz.

Mit dem ersten Release hat Skype 2003 eine der größten P2P-Architekturen ausgerollt. Jeder Client wurde dabei zu einem Knoten des P2P-Netzes, welcher weitestgehend losgelöst vom Backend operieren konnte. Das Backend bestand primär aus PostgreSQL-basierten Datenbank-Services, die Logik wurde überwiegend im Client implementiert.

Bezogen auf das CAP-Theorem, wonach in einem verteilten System von den drei Anforderungen Konsistenz (Consistency), Verfügbarkeit (Availability) und Partitionstoleranz nur zwei umfassend erfüllt werden können, konnte so maximale Verfügbarkeit und Partitionstoleranz (»AP«) sichergestellt werden.

Nach der Übernahme 2011 durch Microsoft wurde auch die Architektur hinterfragt. Dabei stellte sich heraus, dass die Welt beziehungsweise die Anforderungen sich geändert hatten. Desktop-Applikationen waren nicht mehr dominant, sondern mobile Anwendungen. Serverkosten hatten sich drastisch reduziert, dafür sollte Messaging beispielsweise auch offline möglich sein. Außerdem wurden Funktionen wie server-weites Suchen oder Vorschläge benötigt. Außerdem erschien es nicht mehr sinnvoll, die Logik im Client vorzuhalten. Die Funktionen des Skype-Clients wurden deshalb in mehreren Teilschritten auf eine verteilte Service-Architektur migriert, welche sich zum Teil natürlich auch bei bekannten Services von Microsoft bedient, beispielsweise MSA für Login:

Die Migration wurde dabei durch A/B Tests unterstützt, für welche eigens ein sogenannter Experimentation and Configuration Service (ECS) aufgebaut wurde, der mittlerweile bei ganz Microsoft im Einsatz ist.

Skypes ehemalige P2P-Architektur soll ab Herbst 2018 Geschichte sein. Interessant, dass auch ein IT-Gigant wie Microsoft für so ein Migrationsvorhaben immerhin 7 Jahre gebraucht hat.

Explaining Artificial Intelligence to Schoolchildren

Der Referent dieses Vortrags ist als Entwickler bei IBM für deren Programm Watson tätig und hat unter anderem eine web-basierte Lernumgebung rund um Machine Learning für Kinder erstellt. Da Machine Learning in immer mehr Bereiche vordringt, gab es für die anwesenden Entwickler auch gleich ein paar beruhigende Worte von einem, der seit Jahren in dem Umfeld professionell tätig ist:

»Artifical Intelligence adds to a developer’s toolbox, it doesn’t replace him.« –Dale Lane

Ihm ist es wichtig, aufzuzeigen, was Machine Learning als Teilbereich der Künstlichen Intelligenz (Artifical Intelligence) ist, was damit machbar ist und wo die Grenzen sind; und das möglichst auch schon Kindern, da diese zukünftig immer mehr mit entsprechenden autonomen Systemen konfrontiert sein werden.

»Machine Learning is…Learning how to perform a task from a collection of examples.« –Dale Lane

In der Lernumgebung werden Kinder auf spielerische Art und Weise durch die notwendigen Schritte für Machine Learning geführt:

• Sammeln von beispielhaften Daten (Bilder, Zahlen, Texte) für die Aufgabe
• Trainieren des Computers anhand der Beispieldaten (hier erfolgt das Lernen)
• Programmieren einer Anwendung, welche anhand des Gelernten entsprechende Aufgaben ausführt

Im ersten Schritt dreht es sich darum, entsprechende Daten für das jeweilige Vorhaben in ausreichender Menge zu sammeln – zum Beispiel Bilder von Gesichtern. Im zweiten Schritt wird das System dann trainiert. Beispielsweise werden die Bilder in zwei Gruppen von Menschen mit glücklichem und unglücklichem Gesichtsausdruck aufgeteilt. Im dritten Schritt wird über Scratch, die visuelle Programmiersprache für Kinder, welche in der Lernumgebung mit der API von Watson integriert ist, ein einfaches Programm geschrieben. Im genannten Beispiel würden neue Fotos anhand des Gesichtsausdrucks in glücklich oder unglücklich eingeordnet werden.

Wichtig ist dem Referenten dabei insbesondere auch immer wieder die Grenzen von Machine Learning aufzuzeigen. Konkret zum Beispiel die vielen Möglichkeiten, entsprechende Systeme bewusst oder unbewusst mit Vorurteilen anzulernen. Googles Bildersuche, die vor einiger Zeit die Bilder von zwei Afroamerikanern mit der Kategorie Gorilla versah, ist da nur ein Beispiel von vielen.

The Story of Teams, Autonomy, and Servant Leadership

Dieser Vortrag zeigte, wie Booking.com seine Entwicklungsteams im agilen Kontext aufgestellt hat und insbesondere wie die Entwicklung zum aktuellen Status Quo anhand von gesteuerten Experimenten faktenbasiert erfolgte. Dabei war der Fokus insbesondere auf der Rolle Teamleiter – nicht verwunderlich, da diese Rolle in den agilen Entwicklungsansätzen wie beispielsweise Scrum nicht weiter definiert ist, was von vielen so interpretiert wird, als bräuchte es gar keiner Führung im agilen Kontext. Das dem nicht so ist, zeigte der Referent, selbst Führungskraft bei Booking.com, entsprechend auf.

Booking.com ist von acht Mitarbeitern im Jahr 2000 auf aktuell über 15.000 angewachsen, wovon derzeit über 1.500 Mitarbeiter in der IT tätig sind. Um 2014 waren rund 500 Mitarbeiter in der IT. Jedes Team hatte dabei einen Teamleiter und einen Product Owner, die wiederum an einen Senior Teamlead (Abteilungsleiter) und einen Senior Product Owner berichtet haben, welche dann direkt entsprechend an den CTO und CPO berichtet haben:

Aufgabe des Teamleiters war zu rund ⅔ fachliche Mitarbeit im Team und zu rund ⅓ klassische Teamleitungsaufgaben wie zum Beispiel Prozesse, teamübergreifende Kommunikation, Mitarbeiterentwicklung und -leistung. Der Product Owner war für Aufgabenpriorisierung, Backlog-Verwaltung, Metriken und die Kommunikation mit dem Business beziehnungsweise Fachbereich verantwortlich.

Zwischen 2015 und 2016 setzte dann ein extremes Wachstum des Unternehmens ein, was zu einer Verdoppelung der Anzahl der Mitarbeiter in der IT auf rund 1.000 führte. Dies machte auch andere Führungsansätze notwendig, weshalb autonome Teams als Lösungsansatz untersucht wurden. Damit gemeint war, dass Teams ohne Teamleiter arbeiten und alle Teammitglieder gleichermaßen für entsprechende Aufgaben verantwortlich sind. Die bisher vom Teamleiter quartalsweise und 1:1 erfolgten Performance Reviews erfolgten jetzt beispielsweise in einer gemeinsamen Teamsitzung. Spannend, inwiefern das arbeitsrechtlich in Deutschland abbildbar wäre. Der Product Owner als Verantwortlicher für die geschäftlichen Aspekte blieb erhalten, die Teams berichteten innerhalb der IT jetzt direkt an den Senior Teamlead:

Das Ganze wurde als Experiment mit 26 von 84 Teams in der IT erprobt. Fokus war dabei auf der Effektivität der Teams analog zu Googles »Perfect Team« und den entsprechenden Metriken.

Booking.com stellte im Laufe des Experiments drei Hauptprobleme fest. Erstens konnte das angestrebte Wachstum in den autonomen Teams ohne entsprechende Unterstützung (durch die Teamleitung) nicht wie gewünscht sichergestellt werden. Zweitens verändern sich Teams (siehe hierzu auch weiter oben zum Workshop vom Dienstag »Coaching the Team System«) und brauchen auch dabei Unterstützung. Drittens waren die Senior Teamleads mit der Vielzahl an Teams, die direkt an sie berichteten, trotz der vermeintlichen Autonomie überfordert.

Den Problemen wäre vermutlich noch zu begegnen gewesen, die wesentliche Kennzahl für Booking.com, das Engagement der Mitarbeiter, ging in diesem Experiment autonomer Teams ohne Teamleitung allerdings erheblich zurück. Es musste also etwas verändert werden. Booking.com versuchte dabei, das Beste aus beiden Ansätzen zu nehmen und kam zu folgender Erkenntnis:

Es sollte also autonome Teams, aber mit Teamleiter geben. Hierfür wurde die Aufgabenbeschreibung und insbesondere das Skillprofil der Teamleitung in Richtung Servant Leadership geschärft. Die »neue« Teamleitung hat also keine beherrschende Macht mehr über das Team, sondern ist Teil desselben. Die Performance Reviews werden beispielsweise weiterhin analog zum autonomen Team in einer gemeinsamen Sitzung abgehalten, in der jetzt auch der Teamleiter mit bewertet wird und selbiger auch nur eine Stimme, wie jedes Teammitglied hat.

Die Teamleitung arbeitet nach wie vor fachlich mit, aber nur noch unter 50 % und verwendet zukünftig mehr als die Hälfte seiner Zeit auf Personalentwicklung:

Da es nicht leicht ist, solche Teamleiter zu rekrutieren, setzt Booking.com agile Coaches ein, um die Teamleiter hier entsprechend zu unterstützen und zu entwicken.

Wichtig auch die Erkenntnis, was Autonomie für Booking.com nicht ist:

• Alleine arbeiten,
• Anarchie oder
• Vernachlässigung.

Die Erkenntnis aus dem gesteuerten Experiment von Booking.com ist, dass Teams auch eine Teamleitung brauchen, andernfalls sinkt die Effektivität. Teamleitung ist hier aber keine beherrschende, sondern eine dienende Rolle mit entsprechenden Aufgaben.

AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web

Nach der interessanten Einführung in WebAssembly am Dienstag zeigte der Referent dieses Vortrags, wie AutoCAD mittels WebAssembly erfolgreich für das Web portiert wurde. Es handelt sich dabei um eine C/C++-Desktop-Applikation, deren Codebasis rund 15 Millionen Codezeilen umfasst und die bis ins Jahr 1982 zurückreicht.

Als die Entwicklungsmannschaft vor der Aufgabe stand, diese Applikation fit für das Web zu machen, wurde relativ schnell klar, dass ein Neuschreiben aufgrund des Umfangs keine Option war, da es weder nachhaltig ist, zwei Entwicklungslinien für so ein Produkt aufrechtzuerhalten, noch so ein Unterfangen auch nur ansatzweise schnell genug wäre. Ganz zu schweigen vom 2nd-System Effect. Deshalb wurde sich auf die Option der Cross-Kompilierung der Codebasis fokussiert. Es wurden verschiedene Ansätze (Flash, JavaScript, asm.js) probiert, bevor der Durchbruch mit WebAssembly gelang. Als Toolchain kommen dabei Emscripten und WebAssembly Binaryen zum Einsatz.

Mit einem einfachen Kompilieren einer so großen Codebasis war es natürlich nicht getan. Es mussten sowohl an der Codebasis als auch an der Toolchain Anpassungen vorgenommen werden, um folgenden Herausforderungen zu begegnen:

• Kompilier- und Build-Zeit der Codebasis
• Startzeit der Applikation
• Desktop- gegenüber Web-Paradigma.

Die beiden ersten der eben genannten Punkte hängen natürlich direkt mit der umfangreichen Codebasis zusammen. Aber gerade der letzte Punkt, die gegenläufigen Entwicklungsparadigmen zwischen Desktop- und Web-Applikationen, betreffen jeden, der eine entsprechende Software portieren möchte. Als Beispiel wurden synchrone und asynchrone Programmierprobleme im Web genannt. Die Behandlung von blockierenden Aufrufen ist in Desktop-Programmen anders als im Web. Und dann wurde noch Shared Memory angeführt. Desktop-Applikationen erlauben synchrone Schreibzugriffe, da es dort Shared Memory gibt, um Daten zu teilen – im Web gibt es das so nicht.

Für die genannten Probleme fanden die Entwickler bei AutoCAD aber Lösungen, vielleicht nicht in Tagen, so aber in der Regel doch in Wochen oder zumindest Monaten, was in keinem Vergleich zu dem mehrjährigen Neuschreiben der Software steht. Die Applikation steht durch Cross-Kompilierung mittels WebAssembly heute auch als Web-Applikation zur Verfügung.

Breaking Codes, Designing Jets and Building Teams

Dieser Vortrag hätte auch durchaus als Keynote laufen können. Der Referent, Randy Shoup, hat 25 Jahre Erfahrung im Engineering bei den Größen des Silicon Valleys, beispielsweise Director of Engineering bei Google, Chief Engineer bei eBay, Tech Lead bei Oracle und aktuell VP Engineering bei WeWork. Er ist aber auch der Sohn von Richard Shoup, Gründungsmitglied des berühmten Xerox Palo Alto Research Center. Damit hat der Referent natürlich Einblick in die Geschichte des (IT) Engineering wie wenig andere. Und dessen bediente er sich, um anhand von drei Beispielen für sehr effektive Engineering-Teams deren Gemeinsamkeiten herauszuarbeiten.

Sein erstes Beispiel für ein effektives Team betraf die Code-Brecher der britischen Militäreinrichtung Bletchley Park, welche den ersten programmierbaren digitalen Computer bereits 1943 vollständig im Geheimen bauten. Es wird geschätzt, dass dank Bletchly Park der zweite Weltkrieg um zwei Jahre verkürzt und somit 14 Millionen Leben gerettet werden konnten (=> Zweck). Trotzdem es sich um eine Militäreinrichtung handelte, gab es wenig Hierarchie und eine offene => Organisationskultur. Jedes Team war cross-funktional aufgestellt, zwischen den Teams herrschte allerdings absolute Geheimhaltung (also Unabhängigkeit). Aufgrund der sich ständig ändernden Codes mussten auch die Teams permanent lernen und iterieren (=> technische Exzellenz). Dabei waren die Teams extrem divers mit einer Frauenquote von bis zu 75 % (=> Menschen). Bekanntheit hat hierbei natürlich insbesondere Alan Turing erlangt, aber auch Ian Fleming, der Erfinder von James Bond, hat hier gearbeitet.

Als zweites Beispiel für außergewöhnliche Engineering-Leistungen wurde Lockheeds sogenannte “Skunk Works” Advanced Developments Gruppe aufgeführt. Seit Gründung 1943 wurden hier Generation um Generation der weltweit am schnellsten und höchsten fliegenden sowie geheimsten Flugzeuge entwickelt, wie zum Beispiel die F-117A Nighthawk. Entgegen dem im modernen Flugzeugbau wohl üblichen Vorgehen, erfolgten Design, Entwicklung und Bau hier innerhalb einer cross-funktionalen Einheit, wo alle beteiligten Rollen eng zusammen saßen (“Co-Location”) und beispielsweise auch der Testpilot eng in den Entwicklungsprozess involviert war (=> Organisationskultur). Dabei war jeder für Qualität verantwortlich:

We made every shop worker who designed or handled a part responsible for quality control. Any worker – not just a supervisor or a manager – could send back a part that didn’t meet his or her standards.

Es wurde schon sehr früh umfassend Gebrauch von Modellen, Simulationen sowie Mockups und Prototypen zum Verifizieren von Hypothesen gemacht (=> Technische Exzellenz). Und auch dieses Team war von Anfang an durch Diversivität geprägt. So war beispielsweise Mary G. Ross als erste amerikanische Ureinwohnerin Gründungsmitglied und Engineer der Skunk Works Group (=> Menschen).

Als drittes Beispiel führt Shoup das Xerox PARC an, welches 1970 gegründet wurde und dessen Erfindungen die Grundlage unserer heutigen digitalen Welt sind. Beispielsweise wurden hier Smalltalk als »Mutter der Objektorientierung«, das erste graphische Benutzerinterface mit überlappenden Fenstern als Basis für Apple und Microsoft Windows, die WYSIWYG Textbearbeitung, Ethernet oder auch der Laserdrucker genannt.

Kurzer Einschub an dieser Stelle: Die Erfindung der Computermaus wird auch gerne wahlweise dem Xerox Parc oder Doug Engelbart zugeschrieben, es scheint aber so, dass hier tatsächlich Telefunken aus Deutschland die Nase vorn hatte.

Die => Organisationskultur des Xerox PARC war flach, ohne Hierarchie und versammelte Talente wie Alan Kay, Adele Goldberg und Richard Shoup (=> Menschen) aus der Industrie und dem universitären Bereich.

Aus diesen drei Beispielen für extrem effektive Engineering-Einheiten konnte der Vortragende die folgenden gemeinsamen Eigenschaften als Prinzipien effektiven Engineerings ableiten:

• Zweck: Die Teams müssen »groß« denken dürfen, dabei aber fokussiert auf ein wichtiges und motivierendes Ziel für die Organisation sein.
• Organisationskultur: Cross-funktionale »Full Stack« Teams sind für diese Art von Arbeit am effektivsten, das Team muss maximale Autonomie bei minimaler Bürokratie und minimaler zentrale Kontrolle haben; Zusammenarbeit und eine Kultur des Lernens sind weitere Schlüssel zum Erfolg.
• Menschen: Unabhängig von ihrem Hintergrund sind die besten Leute für den jeweiligen Job zu engagieren, dabei ist Diversität wichtig; die Menschen sind gut zu behandeln – schlimm, dass das immer noch erwähnenswert ist, siehe hierzu auch unsere Definition von Leistung, die immer schon die ethische Komponente umfasste.
• Technische Exzellenz: Systemisches Denken und die Suche nach ganzheitlichen Lösungen sind der Schlüssel zu technischer Exzellenz. Dabei muss pragmatisch geliefert werden und konstantes Feedback in alle Prozesse integriert werden.

Vieles davon findet sich heute in den Prinzipien von Agile, Lean oder auch DevOps wieder, wurde dort aber nicht »erfunden«, sondern geht auf Beispiele wie die hier genannten zurück.

Empowering Agile Self-Organized Teams With Design Thinking

Dieser Vortrag gliederte sich in drei Teile. Zunächst stellte der Referent ausführlich seinen grundsätzlichen methodischen Rahmen vor. Anschließend ging er über eine Fallstudie der agilen Transformation einer konkreten Infrastruktureinheit auf Design Thinking für die Gestaltung von Organisationen ein. Abschließend stellte er das theoretische Gerüst von Design Thinking vor.

Der grundsätzliche methodische Rahmen des Referenten war geprägt von »Klassikern« agiler Management-Ansätze.

»People are already doing their best; the problems are with the system. Only management can change the system.« —W. Edwards Deming

»Every system is perfectly designed to get the result that it does.” ― W. Edwards Deming

Aus Sicht des Referenten gibt es nicht den einen und besten Weg, etwas zu organisieren und somit auch nicht »das eine« Organisationsdesign. Er spricht sich auch klar und deutlich gegen klassische autoritäre Managementansätze aus:

»Organizations that operate from the authoritarian, hierarchical, command and control model, where the top leaders control the work, information, decisions, and allocation of resources, produce employees that are less empowered, less creative, and less reductive.« –Creativity and Innovation: The Leadership Dynamics. Journal of Strategic Studies

Dabei hob er auch noch einmal die Quellen von Macht in Organisationen auf Basis von French und Ravens grundlegeneder Arbeit hierzu aus dem Jahre 1959 hervor:

• Legitime Macht durch formale Autorität in einer Hierarchie.
• Wissensmacht durch Expertenwissen auf einem Gebiet.
• Macht durch Vergabe von Belohnung wie beispielsweise finanzielle aber auch immaterielle Anreize (Lob, Erweiterung des Verantwortungsbereiches).
• Macht durch Zwang wie beispielsweise die Möglichkeit, Degradierungen oder Entlassungen vorzunehmen.
• Macht durch Identifikation setzt charismatische Persönlichkeiten voraus, mit denen man sich identifizieren möchte.
• Informationsmacht entsteht durch die Fähigkeit, den Fluss von Informationen und auch Desinformationen in Organisationen steuern zu können.

Womit er zum »Empowerment«, also der Ermächtigung von Mitarbeitern überging. Dies bedeutet für den Referenten, dass eine Gruppe von Mitarbeitern Entscheidungen in einem gewissen Rahmen eigenständig und ohne weitere Rückversicherung beim Management treffen kann. Dem Management kommt hierbei eine besondere Bedeutung zu, weshalb der Referent anhand des sogenannten »Leadership Continuums« verschiedene Führungsansätze diskutierte:

Beide Enden des dargestellten Kontinuums schnitten dabei nicht besonders gut ab. Diktatorische Führung führt dazu, dass Mitarbeiter sich nicht ermächtigt fühlen und ihnen die Möglichkeit genommen wird, selbst Lösungen zu suchen, welche in der Regel besser sind, da sie näher am Problem sind. Das andere Ende, also vollständige Ermächtigung der Mitarbeiter, ist dabei allerdings auch nicht der Königsweg. Der Referent spricht hierbei auch vom Hippie, der gerade noch Ziele vorgibt und dann verschwindet. Dabei ist für die Mitarbeiter dann häufig keine Strategie erkennbar und es wird wenn überhaupt noch lokal optimiert.

Der Lean Leader hingegen:

• Klärt die Vision und Absicht, also das Warum und Was,
• benennt dabei aber auch die Grenzen und
• vergibt Entscheidungsbefugnisse.
• Er lebt entsprechendes Verhalten vor und
• erzeugt Vertrauen.
• Er bevorzugt Experimente, die auch scheitern können, statt Lösungen vorzugeben.

Der erste Teil des Vortrags schloß mit dem folgenden Zitat ab:

»Individuals and teams closest to the problem, armed with unprecedented levels of insights from across the network, offer the best ability to decide and act decisively.« -General Stanley McChrystal

Interessanterweise spiegelt dieses Idealbild die Situation in Teilen der US-Armee, einer bis dato doch sehr hierarchischen Organisation wider, die sich aber aufgrund geänderter Rahmenbedingungen auch entsprechend an ein neues Führungs- und Organisationsprinzip angepasst hat.

Ausgangssituation der Fallstudie im zweiten Teil des Vortrags war folgendes, wohlbekanntes Spannungsfeld zwischen Fachbereich und IT-Infrastruktur-Entwicklungsteam eines großen Pharmaunternehmens, welches nach Wasserfall-Modell arbeitete:

»You deliver last years tech, in twice the time, for three times the price, and a fraction of the value!«

Nur sechs Wochen nach Umstellung auf eine agile Arbeitsweise konnten bereits folgende Erfolge vermeldet werden:

• Reduzierung der Lead Time für Services von 9 Monaten auf Tage, häufig Stunden.
• Reduzierung ungeplanter Arbeit von 64 % auf 28 %.
• Erhöhung der Zufriedenheit des Fachbereichs um 72 %.

Dies wurde folgendermaßen erreicht:

1. Aufsetzen eines Kanban-Systems
2. Visualisierung aller Arbeit im Team
3. Messen des Wertstroms
4. Identifizierung aller Schritte, insbesondere Verschwendung (Frei-/Übergaben)
5. Einbeziehung der Anwender
6. Einbindung relevanter Stakeholder (Compliance, Security, Finance, …)
7. Durchführung einer Designstudie für den neuen Prozess
8. Prototypisierung, Testen, Messen und Lernen für diesen neuen Prozess
9. Minimum Viable Services entwicklen
10. Iterieren, Testen, Messen, Lernen, Iterieren, Wiederholen

Der Wertstrom-Messung kam dabei eine besondere Bedeutung zu, denn darüber lässt sich:

• Der Grund für Falschbedarf erkennen.
• Verschwendung im System identifizieren, wie zum Beispiel
  – Warteschlangen
  – Unnötige Freigaben
  – Rückgaben und Nacharbeiten.

Den dritten Teil des Vortrags zum Hintergrund von Design Thinking leitete der Referent folgendermaßen ein:

»In practice it combines empathy to enable deep understanding and reframing of a problem in context, divergence to generate insights and solutions; visualization and prototyping to document, connect and test ideas, and rationality to analyze and assess the solutions outcome.« – TIM BROWN, IDEO

Hintergrund sind dabei die Grundlagen von Peter G. Rowe »Design Thinking« aus dem Jahr 1987 und Richard Buchanans »Wicked Problems in Design Thinking« von 1992. Wichtig ist dabei, analog zum Brainstorming, zunächst in einem sogenannten Divergence-Schritt möglichst viele Optionen zu generieren, um im folgenden Convergence-Schritt durch Entscheidungen den Lösungsraum wieder einzugrenzen:

Ohne das Problem richtig verstanden zu haben, kann auch keine gute Lösung gefunden werden, denn

»A problem well stated is mostly solved.« — CHARLES KETTERING

Hierzu ist wiederum eine empathische Herangehensweise notwendig, denn in jedem Problem, welches zu uns gebracht wird, steckt die Chance, im Rahmen von Design Thinking etwas zu verbessern.

»The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership.« – COLIN POWELL

Was dann alles zusammengefasst zum sogenannten Double Diamond Modell des Design Thinking führt:

Software Is Eating the World, ML Is Going to Eat Software

Der Referent dieses Vortrags ist Engineer im Developer Infrastructure Team von Facebook. Der Einblick ins Engineering bei Facebook und dass sie dort überhaupt genau so ein Team haben, welches Tools und Infrastruktur für Entwickler zentral bereitstellt, war dabei gleich die erste interessante Information.

Facebook möchte Machine Learning in jeder Schicht ihres Technologiestacks integrieren, um Entwickler produktiver und Prozesse und Infrastruktur effizienter zu machen. Machine Learning ist dabei für Facebook nur ein weiteres Tool, wie beispielsweise objektorientierte oder funktionale Programmierung, welche auch entsprechend tief in die Programmiersprachen und Entwicklertools, wie zum Beispiel IDEs oder Versionskontrolle integriert wird.

Machine Learning kommt da zum Einsatz, wo viele Daten anfallen, um Vorhersagen abzuleiten und Klassifizierungen sowie Cluster zu bilden. Der Referent nannte dabei zwei konkrete Anwendungsfälle in seinem Umfeld bei Facebook: zum einen das Cache Management in der Infrastruktur und zum anderen die Autovervollständigung ganzer Codeteile in der Entwicklung. Ausgangssituation für Letzteres ist dabei folgende Erkenntnis:

»70 % des Codes auf Github ist Copy & Paste.« – Joe Pamer

Da der meiste Code also sowieso kopiert wird, sollen Entwickler in ihrer IDE, ähnlich zur Autovervollständigung von beispielsweise Schlüsselwörtern der jeweiligen Programmiersprache, Vorschläge für ganze Codeteile, wie zum Beispiel Methoden oder Klassen bekommen, die an die jeweilige Stelle im Code passen könnten. Das geht dann über einfache Code-Suche, wie wir zum Codesharing mit Tools wie Sourcegraph und Searchcode skiziiert haben, hinaus und schon mehr in Richtung Deep Code Search, aber eben auf Basis der umfangreichen Codebasis von Facebook und mit Machine Learning, da Code ja auch nur strukturierte Daten sind. Mit diesem Ansatz konnte die Produktivität der Entwickler bei Facebook bereits um 14 % gesteigert werden. Bei geschätzten 10.000 Entwicklern, die für Facebook arbeiten, ist dies ein erheblicher Produktivitätsgewinn.

Einschätzung

Die Workshops waren unserer Einschätzung nach nicht ganz »bleeding-edge«, die Keynotes und Vorträge durchaus. Wobei die New Yorker QCon auf uns insgesamt etwas kleiner und vermutlich da eben nicht im Silicon Valley gelegen, auch nicht ganz so pulsierend wie die Veranstaltung in San Francisco gewirkt hat. Egal wo, die Veranstaltungen sind immer einen Besuch wert, denn auch wenn es heutzutage eigentlich dafür keinen Grund mehr geben sollte, so sind die Themen hier entsprechenden Veranstaltungen in Deutschland dann doch immer noch ein Stück voraus.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Hintergrund

Vereinfacht ausgedrückt, besagt das mooresche Gesetz, dass sich die Leistungsfähigkeit von Computer-Prozessoren etwa alle 18 Monate verdoppelt. Leistungsfähigkeit wird hierbei mit der Anzahl von Transistoren gleichgesetzt, was zwar eben eine Vereinfachung ist, aber eine allgemein akzeptierte. Das »Gesetz« ist auch eher als Faustformel zu verstehen, welche aber empirisch belegt ist.

Für Software fehlte so eine allgemein anerkannte Faustformel bislang, wie beispielsweise auch die New York Times feststellte:

»There are no such laws in software.«

Gegenfalls wäre hier das Wirthsche Gesetz anzuführen, welches aber nur recht allgemein feststellt, dass »die Software schneller langsamer wird, als die Hardware schneller wird«. Demgegenüber stellte Marc Andreessen aber fest: »Software is eating the world«.

Wie soll aber die Leistungsfähigkeit von Software beurteilt werden? Vielleicht durch die Anzahl ihrer Features? Dann stellt sich gleich die Frage, wie man Features misst und vergleicht, womit man zu aufwendigen Verfahren, wie etwa der Function Point Analyse kommt. Nach unserer Erfahrung wird selbige nur selten eingesetzt, weshalb sie sich für einen empirischen Nachweis vermutlich nicht eignet. Natürlich ist Softwareentwicklung [komplex][3] und lässt sich nur schwerlich auf eine einfache Metrik reduzieren, aber vielleicht ist eine Vereinfachung analog zum mooreschen Gesetz der Hardware auch für die Software eine Lösung.

Michiel van Genuchten und Les Hatton zeigten einen entsprechenden Ansatz erstmals 2012 in ihrem Artikel »Compound Annual Growth Rate for Software« [2] im IEEE Software Magazine auf.

Lines of Code

Die Autoren umgehen die Frage der Leistungsfähigkeit von Software hier und messen stattdessen, wie sich die Codebasis von verschiedenen Softwaresystemen hinsichtlich ihrer Größe in Anzahl der Codezeilen (»Lines of Code« (LoC)) über die Zeit entwickeln. In Anlehnung an die Anzahl Transistoren des mooreschen Gesetz durchaus nachvollziehbar. Die zugrunde liegende Codebasis umfasste zwei Open und 6 Closed Source Systeme. Dies reichte zwar vielleicht noch nicht für eine statistisch relevante Aussage, das Ergebnis erschien mit einem Faktor von 1,16 aber schon recht stabil. Demnach verdoppelt sich Software also alle rund 5 Jahre im Umfang:

»If we don’t know anything about a certain software system at hand, as a good starting point, we could assume it has a CAGR of the median value 1.16 and therefore doubles in size every four to five years.«

Interessanterweise stellen wir bei Diskussionen um die Messgröße Lines of Code in der Softwareentwicklung häufig sehr dogmatisch ablehnende Haltungen fest, ohne dass dann aber Alternativen aufgezeigt werden können. Natürlich sind die Lines of Code eine Vereinfachung der komplexen Softwareentwicklungswelt. Aber alle Metriken sind Reduzierungen und können und wollen nicht die ganze Komplexität in einer Größe zeigen – es sind Modelle. Wenn es um Fitness oder Gesundheit geht, schauen wir uns genauso vereinfachend zunächst häufig das Gewicht in kg einer Person an. Was aber nun, wenn jemand mehr Sport macht, dabei an Muskelmasse zunimmt und entsprechend sein Gewicht erhöht; ist das jetzt gut oder schlecht? Auch hier reicht das eindimensionale Körpergewicht in kg einer Person als Kennzahl alleine nicht mehr aus, ist aber ein guter Einstieg in die Diskussion und weitere Analyse. Genauso sollten wir es mit der Kennzahl LoC in der Softwareentwicklung halten.

Compound Annual Growth Rate

Die Compound Annual Growth Rate (CAGR) oder jährliche Wachstumsrate ist eine »in der Betriebswirtschaft und Volkswirtschaft […] wesentliche Kennziffer«. Sie ist insbesondere im Finanzsektor etabliert, um zum Beispiel das komplexe Wachstumsverhalten von Finanzinstrumenten abzubilden. Da die CAGR auch Eigenschaften aufweist, die für das komplexe Verhalten von Software relevant sind, spricht vieles dafür, sie entsprechend zu übernehmen:

»Sie stellt das durchschnittliche jährliche Wachstum einer zu betrachtenden Größe dar. […] Tatsächliche Ausschläge der Folgejahre in der Zwischenzeit wirken sich dabei nicht aus, die Wachstumsrate ist konstant.«

Auf Software angewandt, gleichen sich Effekte, wie zum Beispiel durch Refactoring-Maßnahmen, welche die Codebasis kurzeitig in die eine oder andere Richtung verändern können, ohne entsprechende Auswirkung auf die Funktionalität zu haben, dem folgend über die Zeit auch wieder aus.

Follow-up

Da dem eingangs erwähnten Artikel noch nicht genug statistisch relevantes Material für eine empirische Aussage zugrunde lag, haben Les Hatton und Michiel van Genuchten, diesmal erweitert um Diomidis Spinellis, 2017 »The long‐term growth rate of evolving software: Empirical results and implications« [1] veröffentlicht. Darin ermitteln sie den CAGR für über 404 Millionen Zeilen Code aus Open als auch Closed Source Software Systemen.

Mit diesem erweiterten Datensatz konnten sie eine jährliche Wachstumsrate des Quellcodes von Softwaresystemen von 1,21 ermitteln. Ohne weitere Kenntnis um ein System kann man demzufolge davon ausgehen, dass ein Softwaresystem den Umfang seines Quellcodes alle 42 Monate verdoppelt.

Interessant sind hier auch die in der Studie ausgewiesenen Unterschiede zwischen einzelnen Produkten und Branchen. Sun Solaris von Oracle und somit ein Closed Source System weist nur einen CAGR von 1,09 beziehungsweise eine Verdoppelung alle 8 Jahre auf, wohingegen der Open Source Linux Kernel auf einen CAGR von 1,32 kommt und sich somit schon nach 2,5 Jahren verdoppelt hat. Wobei die Autoren ansonsten keine Beziehung zwischen dem CAGR und der Art der Software (Open vs. Closed Source) herstellen konnten. Software im sicherheitskritischen Bereich wächst der Untersuchung zufolge mit einem CAGR für ein Flugmanagementsystem von 1,10 erheblich langsamer als beispielsweise eine Navigtionssoftware mit 1,23.

Anwendung

Software wächst. Um wie viel genau ist individuell unterschiedlich, im Schnitt kann man aber davon ausgehen, dass der Umfang an Quellcode, den man zu verwalten hat, pro Jahr um mehr als 20% zulegt. Darauf muss man sich als Entwicklungsleiter einer Softwareeinheit strukturell einstellen.

Aus der Finanzwelt weiß man, dass niemand den Markt schlägt, man sein Geld also beispielsweise besser in einen passiv gemanagten Indexfonds anlegt, anstatt es einem aktiv gemanagten Fond anzuvertrauen. Auf die Softwareentwicklung umgemünzt, empfehlen die Autoren der Studie, eine Roadmap oder einen Produktmanager, welche beispielsweise eine Verdoppelung der Software in einem Jahr nahelegen, sehr kritisch zu hinterfragen. Was genau werden wir anders machen, um soviel besser als der »Markt« zu sein?

Aus eigener Erfahrung heraus können wir auch anderherum bestätigen, dass Software wächst, zum Teil ob man nun will oder auch nicht. Wir kennen Softwaresysteme, von denen Unternehmen sich trennen wollten und daran auch mehr oder weniger aktiv gearbeitet haben und die trotzdem Jahr für Jahr weiter gewachsen sind. Um einen CAGR unter 1 zu erzielen, muss man als Entwicklungsleiter also andersherum auch die entsprechenden Voraussetzungen schaffen. Das bedeutet üblicherweise, im »Eingangskanal« nur noch die absolut notwendigen Anforderungen wie zum Beispiel gesetzliche Anpassungen durchzulassen und auf Umsetzungsseite die Kapazität zu reduzieren. Dies reicht unserer Erfahrung nach alleine aber noch nicht aus, um den CAGR unter 1 zu bringen und den Umfang eines Systems wirklich zu reduzieren. Je nach Struktur der Entwicklungsorganisation kann es beispielsweise helfen, ein dediziertes Team mit dem Abbau zu beauftragen oder aber den Abbau von Code über alle Teams hinweg zu incentivieren.

Ausblick

Moore’s Law nähert sich einem physikalischen Ende. Wie aber beispielsweise auch in dem weiter oben erwähnten Artikel der New York Times formuliert wurde, hat Software keine solchen Begrenzungen:

Software […] is pure abstraction — a building material without material constraints.

Somit ist ein Ende des Wachstums von Software nicht absehbar. Die hier vorgestellte Wachstumsrate erfasst dabei nur, wie ein einzelnes System wächst. Die Menge an Software insgesamt wird noch wesentlich stärker wachsen: »Software is eating the world«. Da Software sich absehbar auch noch selbst vervielfältigt, dürften wir vor einer Art »kambrischen Explosion der Software« stehen.

Zusammenfassung

Software wächst zwar langsamer als Hardware, aber sie verdoppelt ihren Umfang im Schnitt doch auch alle 42 Monate. Dies konnten die Autoren der Studie empirisch nachweisen. Damit haben Beteiligte der Softwareentwicklung mit dem CAGR für Software eine Fautformel an der Hand, die eine ähnliche Qualität wie das mooresche Gesetz für Hardware aufweist. Insbesondere bietet sie sich als Einstiegspunkt für Diskussionen bei individuellen Abweichungen an.

Referenzen

[1] Hatton L., Spinellis D., van Genuchten M., „The long‐term growth rate of evolving software: Empirical results and implications“, J Softw Evol Proc. 2017;29:e1847. https://doi.org/10.1002/smr.1847

[2] M. van Genuchten and L. Hatton, „Compound Annual Growth Rate for Software“, in IEEE Software, vol. 29, no. , pp. 19-21, 2012. https://doi.ieeecomputersociety.org/10.1109/MS.2012.79

[3]: https://dev.atra.consulting/blog/wann-agil-und-wann-klassisch/

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn