Brooks’ Law
“Adding manpower to a late software project makes it later.”
— Frederick P. Brooks, 1975
Brooks’ Law ist keine provokante These.
Sie ist eine strukturelle Beobachtung.
Sie beschreibt ein einfaches Muster:
Wenn ein Projekt bereits verspätet ist,
erhöht das Hinzufügen weiterer Personen die Kommunikations- und Koordinationskosten –
und verzögert es häufig zusätzlich.
Warum passiert das?
1. Einarbeitung kostet Zeit
Neue Personen müssen:
- Domänenwissen aufbauen
- Architektur verstehen
- implizite Annahmen lernen
- bestehende Entscheidungen nachvollziehen
Diese Zeit fehlt dem bestehenden Team.
2. Kommunikationspfade wachsen exponentiell
In einem Team mit n Personen existieren:
n(n − 1) / 2 Kommunikationsbeziehungen.
Das bedeutet:
| Teamgröße | Kommunikationspfade |
|---|---|
| 3 | 3 |
| 5 | 10 |
| 8 | 28 |
| 12 | 66 |
Die Komplexität steigt nicht linear.
Sie explodiert.
3. Arbeit ist nicht beliebig teilbar
Softwareentwicklung besteht nicht nur aus implementierbaren Tasks.
Sie besteht aus:
- Architekturentscheidungen
- Abhängigkeiten
- Integrationspunkten
- implizitem Wissen
Viele Aufgaben lassen sich nicht beliebig parallelisieren.
Was Brooks’ Law nicht sagt
- Es sagt nicht, dass Teams nicht wachsen dürfen.
- Es sagt nicht, dass große Systeme nicht große Teams benötigen.
- Es sagt nicht, dass Skalierung unmöglich ist.
Es sagt:
Skalierung erfordert strukturelle Anpassung.
Verbindung zu anderen Strukturgesetzen
Brooks’ Law steht nicht isoliert.
Es hängt zusammen mit:
- Conway’s Law – Organisation beeinflusst Architektur
- Kommunikationskosten – Struktur erzeugt Koordinationsaufwand
- Teamzuschnitt – Architektur und Team müssen zueinander passen
Ohne strukturelle Anpassung führt Wachstum zu Komplexität.
Häufiger Denkfehler
„Wir sind im Rückstand.
Wir brauchen mehr Entwickler.“
Das Problem liegt selten in der Anzahl der Personen.
Es liegt oft in:
- unklarer Architektur
- fehlenden Entscheidungsrechten
- ungeschnittenen Domänen
- fehlender Modularisierung
Mehr Personen verstärken strukturelle Schwächen.
Sie kompensieren sie nicht.
Konsequenz für professionelle Organisationen
Wenn ein Projekt verzögert ist, sollten zuerst geprüft werden:
- Sind Abstraktionsgrenzen sauber?
- Sind Entscheidungsräume klar?
- Ist die Architektur modular genug?
- Ist Wissen dokumentiert oder personengebunden?
Erst danach sollte Teamgröße angepasst werden.
Ein strukturelles Prinzip
Brooks’ Law ist keine Projektregel.
Es ist ein Hinweis darauf,
dass Softwareentwicklung stark von Struktur abhängt.
Skalierung ist möglich.
Aber nur mit bewusster Gestaltung von:
- Architektur
- Verantwortlichkeiten
- Kommunikationswegen
Technologie skaliert schneller als Organisation.
Brooks erinnert uns daran.