Wir nehmen keine Ratschläge von Nicht-Entwicklern

Die Astrophysik der Software

06.01.2026, Von Stephan Schwab

Wenn kritische Entscheidungen über Software-Entwicklung von Personen getroffen werden, die nie produktiven Code geschrieben haben, zahlen Unternehmen eine wiederkehrende Steuer: gescheiterte Projekte, verlorene Talente und Entwickler, die das neue Framework-Vokabular lernen, während sie auf dem Parkplatz darüber scherzen. Die erfolgreichsten Unternehmen stellen sicher, dass technische Entscheidungen auf echter technischer Expertise basieren.

Die Szene, die alles sagt

Es gibt einen denkwürdigen Moment im Film Armageddon von 1998, in dem Militärvertreter und NASA-Wissenschaftler darüber diskutieren, wie ein Asteroid davon abgehalten werden kann, die Erde zu zerstören. Ein General besteht darauf, dass die wissenschaftlichen Berater des Präsidenten glauben, eine nukleare Explosion könnte die Flugbahn des Asteroiden ändern. Dr. Ronald Quincy, ein britischer NASA-Wissenschaftler – vorgestellt als „so ziemlich der klügste Mann der Welt” – liefert eine vernichtende Antwort:

„Ich kenne den wissenschaftlichen Chefberater des Präsidenten. Wir waren zusammen am MIT. Und in einer Situation wie dieser sollte man wirklich nicht den Rat eines Mannes befolgen, der eine Vier minus in Astrophysik hatte.”

Die Szene findet Resonanz, weil sie etwas einfängt, das wir instinktiv verstehen: Bei komplexen technischen Herausforderungen sollten die Menschen, die das Fachgebiet tatsächlich verstehen, den Ansatz bestimmen. Eine nukleare Lösung mag entschlossen klingen, aber ohne Verständnis von Orbitalmechanik und Physik könnte sie die Lage katastrophal verschlimmern.

Software-Anbieter stehen ständig vor dieser Dynamik. Und zu oft wählen sie das Äquivalent der nuklearen Option.

Der Konferenzraum, in dem Code stirbt

Stellen Sie sich eine vertraute Szene vor: Ein Besprechungsraum, in dem Entscheidungen über Software-Architektur getroffen werden. Am Tisch sitzen Führungskräfte, Projektmanager und vielleicht ein Berater einer renommierten Firma. Die Entwickler – die Menschen, die das Ganze tatsächlich bauen werden – sind entweder abwesend, in der Unterzahl oder sprechen zuletzt.

Jemand schlägt vor, das System in einem Framework neu zu schreiben, über das er in der Harvard Business Review gelesen hat. Ein anderer möchte Blockchain hinzufügen, weil die Firma seines Golfpartners irgendetwas mit Blockchain gemacht hat. Ein Dritter besteht auf einer Anbieter-Lösung, weil die Verkaufspräsentation beeindruckend war.

Die Entwickler wechseln Blicke. Sie wissen, dass diese Ansätze Probleme verursachen werden. Aber sie sind in der Unterzahl, haben weniger Rang oder werden schlicht nicht gefragt.

Warum dieses Muster fortbesteht

Es wäre einfach, Überheblichkeit verantwortlich zu machen, aber das Muster hat strukturelle Wurzeln.

Hierarchie schlägt Expertise. Die Seniorität im Organigramm verleiht Autorität in allen Bereichen. Von der Person, die im Finanzwesen glänzt, wird angenommen, dass sie gültige Meinungen zur Software-Architektur hat. Aber ein brillanter Marketing-Manager wird nicht zum qualifizierten Chirurgen, indem er die Karriereleiter erklimmt.

Abstraktion erzeugt Zuversicht. Software ist unsichtbar. Man kann sie nicht anfassen oder ihre innere Struktur sehen. Das lässt sie einfacher erscheinen, als sie ist. „Es ist doch nur Code, wie schwer kann das sein?” Niemand schaut auf einen Wolkenkratzer und sagt: „Es ist doch nur Stahl und Beton, wie schwer kann das sein?”

Berater sprechen die Sprache der Macht. Externe Berater sind erfolgreich, indem sie Führungskräften sagen, was sie hören wollen – in strategisch klingender Sprache. Die selbstbewusste Vereinfachung des Beraters gewinnt gegen die sorgfältige Qualifizierung des Entwicklers.

Das Framework, das alles richten wird

Vielleicht illustriert kein Muster das Problem besser als Management-Frameworks, die Entwicklungsteams aufgezwungen werden. Eine neue Methodik erscheint – komplett mit Zertifizierungen, Beratern und frischem Vokabular – und verspricht, alle Auslieferungsprobleme zu lösen. Entwickler werden zu Schulungen geschickt. Neue Rituale werden vorgeschrieben. Dashboards werden konfiguriert.

Und dann: nichts ändert sich.

Die Entwickler lernen die Terminologie. Sie nehmen an den vorgeschriebenen Zeremonien teil. Sie aktualisieren ihre Arbeitseinheiten mit den erwarteten Bezeichnungen. Für Führungskräfte sieht alles transformiert aus. Das Unternehmen ist „agil geworden” oder hat „SAFe eingeführt”.

Aber auf dem Parkplatz findet ein anderes Gespräch statt. Entwickler scherzen über das ganze Theater. Sie übersetzen ihre tatsächliche Arbeit in Framework-Sprache für die Status-Meetings und dann zurück, um die Arbeit zu erledigen. Das Framework wird zur Produktivitätssteuer – Aufwand, der bewältigt werden muss, statt ein Werkzeug, das hilft.

Das ist kein Zynismus. Es ist Anpassung. Wenn Menschen, die die Arbeit verstehen, nicht darüber befragt werden, wie die Arbeit zu organisieren ist, ist das unvermeidliche Ergebnis eine Kluft zwischen dem offiziellen Prozess und dem realen. Der reale Prozess läuft in der Form weiter, die funktioniert. Der offizielle Prozess wird zur Aufführungskunst.

Die Tragödie ist, dass viele Frameworks nützliche Ideen enthalten. Aber von oben aufgezwungen, ohne Input von den Menschen, die die Arbeit verstehen, werden selbst gute Ideen zu verhassten Vorgaben.

Die Kosten ignorierter Expertise

Unternehmen, die konsequent die Expertise der Entwickler übergehen, zahlen eine wiederkehrende Steuer:

Projekte scheitern. Wenn technische Entscheidungen von nicht-technischen Personen getroffen werden, funktionieren Systeme oft nicht wie versprochen. Der Asteroid wird nicht zerstört; er zerbricht in Fragmente, die noch mehr Schaden anrichten.

Gute Entwickler gehen. Talentierte Fachleute haben Optionen. Wenn ihre Expertise konsequent ignoriert wird, finden sie Unternehmen, die schätzen, was sie wissen.

Technische Schulden häufen sich an. Die schnelle Lösung, die im Konferenzraum vernünftig erschien, wird zur dauerhaften Belastung der Produktivität.

Innovation stagniert. Wenn Entwickler lernen, dass ihre Expertise nicht geschätzt wird, hören sie auf, sie anzubieten. Sie setzen um, was ihnen gesagt wird, auch wenn sie wissen, dass es nicht funktionieren wird.

Wie echte Expertise klingt

Entwickler versuchen nicht, schwierig zu sein, wenn sie Bedenken äußern. Sie versuchen, Katastrophen zu verhindern.

Wenn ein Entwickler sagt „dieser Zeitplan ist unrealistisch”, wendet er Jahre der Erfahrung an, um zu erkennen, dass bestimmte Dinge bestimmte Zeiträume brauchen. Wenn er eine Technologieentscheidung hinterfragt, berücksichtigt er Faktoren, die erst Monate später sichtbar werden. Wenn er Zeit für Refactoring anfordert, identifiziert er notwendige Arbeit, die entweder proaktiv und günstig oder reaktiv und teuer erledigt wird.

Die Referenzen, die in der Software zählen, sind keine Abschlüsse oder Zertifizierungen. Es ist, Dinge gebaut zu haben, die in Produktion liefen. Systeme gewartet und gespürt zu haben, wie die Abkürzungen von heute zu den Notfällen von morgen werden. Projekte ausgeliefert zu haben, die nicht funktioniert haben, und gelernt zu haben, was zu vermeiden ist.

Raum für technisches Urteilsvermögen schaffen

Unternehmen, die erfolgreiche Software bauen, schaffen Strukturen, in denen technische Expertise technische Entscheidungen informiert.

Entwickler in Entscheidungen einbeziehen. Wenn eine Entscheidung technische Auswirkungen hat – was die meisten Entscheidungen über Software betrifft – sollten Entwickler im Raum sein, nicht Entscheidungen im Nachhinein empfangen.

Expertise angemessen gewichten. Wenn das Thema Astrophysik ist, zählt die Meinung des Astrophysikers am meisten. Wenn das Thema Code-Architektur ist, sollte die Meinung der Entwickler entscheidendes Gewicht haben.

Zwischen Was und Wie unterscheiden. Die Unternehmensführung entscheidet angemessen, welche Probleme zu lösen sind. Technische Fachleute entscheiden angemessen, wie diese Probleme zu lösen sind. Verwechslung zwischen diesen Bereichen ist, wo Dysfunktion entsteht.

Nichts davon bedeutet, dass Nicht-Entwickler keine Rolle haben. Geschäftsexpertise, fachliches Wissen und strategische Vision sind wesentliche Inputs. Aber diese Inputs sollten technische Ansätze informieren, nicht diktieren. Ein CEO könnte angemessen sagen: „Wir müssen das Zehnfache unseres aktuellen Datenverkehrs bewältigen.” Ein CEO sollte dann nicht sagen: „Deshalb müssen Sie Microservices und Kubernetes verwenden” – es sei denn, er hat den technischen Hintergrund, um diese Empfehlung auszusprechen.

Die Frage, die es wert ist, gestellt zu werden

In Armageddon setzt sich der Ansatz der NASA-Wissenschaftler durch. Die grobe nukleare Lösung weicht einem Plan, der die tatsächliche Physik berücksichtigt. Die Mission gelingt, weil Expertise wertgeschätzt wurde.

Schauen Sie sich das nächste Mal, wenn Sie in einer Besprechung sind, in der Software-Entscheidungen getroffen werden, im Raum um. Wer spricht? Wer wird gehört? Gestalten Menschen mit relevanter Expertise die Diskussion, oder werden sie von Menschen überstimmt, deren Referenzen in anderen Bereichen liegen?

Wenn Sie eine Führungskraft sind, die Entscheidungen über Software trifft: Würden Sie einen Operationsplan akzeptieren, der von Ihrem Anwalt entworfen wurde? Eine Rechtsstrategie, die von Ihrem Buchhalter erdacht wurde? Die technische Expertise von Software-Entwicklern verdient denselben Respekt, den Sie jedem anderen professionellen Fachgebiet entgegenbringen würden.

Wir nehmen keine Ratschläge von dem an, der eine Vier minus in Astrophysik hatte. Vielleicht ist es Zeit, dieselbe Logik auf Software-Entwicklung anzuwenden.