Hauptgedanke

Die Softwareentwicklung hat eine Zeit erlebt, in der Analysten spezifizierten und Programmierer Code am laufenden Band produzierten. Die einen dachten, die anderen führten aus. Diese Aufspaltung ist verschwunden: Ein Entwickler übernimmt heute ein Problem von Anfang bis Ende — Architektur, Code, Sicherheit, Auslieferung, Nachverfolgung —, und selbst Architekten, die vom Rest des Teams getrennt sind, werden seltener.

Niemand wünscht sich die Analyst-Programmierer zurück, und niemand vertritt die Ansicht, dass bessere Software entstand, als Denken und Ausführen in zwei verschiedenen Köpfen wohnten. Der Beruf hat durch die Praxis entschieden, ohne Theorie.

Dieser Präzedenzfall hat argumentatives Gewicht: Dieselbe Trennlinie, vom Code ins Produkt verschoben, muss erklären, warum sie dem Schicksal der vorigen entgehen sollte. Die Beweislast wechselt die Seite.

Warum das wichtig ist

Das macht aus einer Meinung über Produktorganisation eine überprüfbare historische Frage: Die Trennung von Konzeption und Ausführung wurde in derselben Branche bereits in großem Maßstab erprobt, und sie wurde aufgegeben.

Es liefert auch eine wahrscheinliche Entwicklungsrichtung statt eines bloßen Dissenses: Aufspaltungen dieser Art weichen zurück, wenn Werkzeuge die Kosten senken, beides zu tun.

Nuancen und Grenzen

Ein Präzedenzfall ist kein Beweis. Die Entwicklung hatte eigene Gründe, die beiden Hälften wieder zusammenzuführen — kurze Zyklen, Continuous Integration, die Kosten eines Rollbacks —, und nichts garantiert, dass sich diese Gründe auf das Produkt übertragen lassen.

Und die Aufgabe war nicht vollständig: Rollen wie Architekt, Staff Engineer oder Tech Lead bestehen fort, mit einem Anteil an Konzeption, der von der Ausführung getrennt ist. Verschwunden ist der Transmissionsriemen, nicht jede Spezialisierung.

Offene Fragen

• Was würde auf der Produktseite die Rolle spielen, die auf der Entwicklungsseite die Kosten eines Rollbacks gespielt haben?