Hauptgedanke

Die Komplexität eines Produkts liest man gewöhnlich an seinem Code ab — Größe der Dateien, Zahl der Schichten, Abhängigkeiten. Das ist der billigste Teil. Ein ausgeliefertes Feature bezahlt man danach bei den Nutzern, die verstehen müssen, wofür es da ist, in den Support-Tickets, die es auslöst, in der Dokumentation, die geschrieben und gepflegt werden muss, in der Stimmigkeit einer Erfahrung, die mit jeder Ergänzung verschwimmt, und in der Fähigkeit der Organisation, zu erklären, was sie eigentlich baut.

Diese Posten werden nicht schneller. Wenn der Code zum schnellen Glied der Kette wird, verschieben sich die Engpässe zu Review, Sicherheit, fachlicher Rahmung, Integration und menschlicher Aufnahmefähigkeit — die sogar kritischer werden als vorher, weil mehr bei ihnen ankommt.

Ein Produkt wird also unlesbar, für seine Nutzer wie für seine Teams, sobald man Features schneller hinzufügt, als man versteht, wofür sie genutzt werden. Mehr Code zu produzieren heißt nicht, mehr Wert zu produzieren; es heißt, die Rechnung an Bereiche weiterzureichen, die dafür nichts zurückgelegt haben.

Warum das wichtig ist

Das ändert, was man zählt, wenn man über eine Ergänzung entscheidet. Die Entwicklungskosten, inzwischen gering, taugen nicht mehr als Anzeiger für die Gesamtkosten, und eine Schätzung, die beim Code aufhört, unterschätzt systematisch, was ein Feature nach sich zieht.

Es gibt Support und Dokumentation auch die Rolle eines Frühwarnsystems: Dort wird eine anderswo beschlossene Komplexität zuerst messbar.

Nuancen und Grenzen

Nicht jede Komplexität trifft die Nutzer. Ein unsichtbares Feature, standardmäßig aktiviert und ohne Bedienoberfläche, kann den Code erheblich belasten, ohne etwas an Adoption oder Support zu kosten — die Rechnung bleibt in voller Höhe bestehen, aber innerhalb des Teams.

Und die Überlegung hat eine Grenze: Eine Organisation, die nur ausliefert, was der Support mühelos verkraftet, würde wenig ausliefern und einem Wettbewerber das Feld überlassen. Die Frage ist, ob man vorsorgt, nicht, ob man verzichtet.

Offene Fragen

• Wie schätzt man vor der Auslieferung den Aufwand an Adoption und Support eines Features ab, statt erst im Nachhinein die Tickets zu zählen, die es auslöst?