Die letzten Tech-Diskussionen habe ich alle abgewürgt.
Nicht weil mich das Thema nicht interessiert. Sondern weil sie zum falschen Zeitpunkt geführt werden. Mit den falschen Fragen. Von Leuten, die Frameworks mit Strategie verwechseln.
Und jetzt höre ich wieder alle rufen: “Wie kannst du das als Entwickler so sehen?”
Ganz einfach: Weil ich in über 20 Jahren gelernt habe, dass fast jede hitzige Tech-Diskussion, die ich je erlebt habe, im Nachhinein irrelevant war. Nicht weil die Technologie egal wäre – sondern weil die Frage falsch gestellt wurde.
Die Diskussion, die du kennst
Du sitzt im Meeting. Oder im Slack-Channel. Oder beim Kaffee mit einem Kollegen. Und dann geht es los:
Angular oder React? Java oder Go? Monolith oder Microservices? Cloud oder On-Prem? PostgreSQL oder MongoDB? REST oder GraphQL?
Alle haben eine Meinung. Alle haben Argumente. Alle haben einen Artikel gelesen, der ihre Position bestätigt. Die Diskussion läuft 45 Minuten, niemand überzeugt den anderen, und am Ende einigt man sich auf “kommt drauf an” – ohne zu klären, worauf es denn ankommt.
Das ist keine Übertreibung. Das ist der Standard.
Der Denkfehler dahinter
Frameworks und Technologien werden in diesen Diskussionen wie Ideologien behandelt. React-Entwickler verteidigen React. Angular-Shops verteidigen Angular. Wer einmal auf Microservices gesetzt hat, sieht überall Microservices als Lösung.
Das ist verständlich – wir investieren Zeit und Energie in das Erlernen von Tools, und dann wollen wir diese Investition gerechtfertigt sehen. Aber es ist professionell gesehen ein Problem.
Ein Hammer ist kein besseres Werkzeug als ein Schraubenzieher. Die Frage ist, was du befestigen willst. Und genau das wird in den meisten Tech-Diskussionen nicht geklärt, bevor die Meinungen fliegen.
Architektur ist die logische Konsequenz von Anforderungen. Keine Ideologie. Und Frameworks sind Werkzeuge zur Umsetzung dieser Architektur. Werkzeuge diskutiert man nicht, bevor klar ist, was gebaut werden soll.
Die fünf Fragen, die zuerst beantwortet sein müssen
Ich hab das über Jahre auf eine einfache Checkliste runtergebrochen. Bevor bei mir irgendeine Tech-Diskussion anfängt, müssen diese Fragen beantwortet sein:
1. Was wollen wir erreichen – und warum? Klingt trivial. Ist es nicht. “Wir brauchen eine neue Website” ist keine Antwort. “Wir brauchen eine Website, die unseren Vertrieb entlastet, weil 60 % der Support-Anfragen Fragen beantworten, die auf der aktuellen Site nicht zu finden sind” – das ist eine Antwort. Aus dieser Antwort folgt eine Architektur-Entscheidung fast von selbst.
2. Welcher Impact wird erwartet – und wie messen wir ihn? Wenn du am Ende nicht weißt, ob die Tech-Entscheidung richtig war, war die Diskussion davor sinnlos. Definiere vorher: Was ist Erfolg? Weniger Support-Anfragen, schnellere Ladezeiten, höhere Conversion-Rate, weniger Deployment-Aufwand? Ohne Messgröße ist jede Tech-Wahl ein Glaubensprojekt.
3. Welche wirtschaftliche Logik steckt dahinter? Ein Startup mit drei Entwicklern hat andere Constraints als eine Bank mit 200. Ein Projekt mit 3-Monats-Deadline hat andere Constraints als ein langfristiges Plattform-Produkt. Die wirtschaftliche Realität des Projekts bestimmt, welche Lösungen überhaupt in Frage kommen – und das filtert die meisten Ideologie-Diskussionen sofort raus.
4. Welche Risiken sind akzeptabel? Eine neue Technologie einzusetzen, die das Team noch nicht kennt, ist ein Risiko. Eine bewährte Technologie einzusetzen, die aber für den Use Case suboptimal ist, ist auch ein Risiko. Wer Risiken nicht explizit benennt und bewertet, trifft keine informierte Entscheidung – er hofft einfach.
5. Welche Zeitachse ist realistisch? Das ist die Frage, die am häufigsten fehlt. Microservices sind eine legitime Architektur-Entscheidung. Aber nicht für ein Team, das in sechs Wochen liefern muss und die Infrastruktur-Komplexität noch nie operativ betrieben hat. Die beste technische Lösung ist wertlos, wenn sie in der verfügbaren Zeit nicht umsetzbar ist.
Was in der Praxis passiert
Ich arbeite seit Jahren für Kunden im Banking- und Enterprise-Umfeld. Atruvia, DERPART – Projekte, wo Compliance, Barrierefreiheit und Stabilität keine optionalen Features sind, sondern harte Anforderungen.
In diesen Projekten entscheidet nicht der persönliche Framework-Favorit des Entwicklers. Es entscheidet die Kombination aus regulatorischen Vorgaben, bestehender Infrastruktur, Team-Kompetenz und Deployment-Prozessen. Das Ergebnis ist manchmal Vue 3 mit TypeScript, manchmal ein solides WordPress mit Custom Elements, manchmal beides parallel.
Nicht weil ich kein Framework bevorzuge. Sondern weil die Anforderungen die Architektur diktieren – und die Architektur das Framework.
Das Interessante: Sobald diese Fragen beantwortet sind, werden viele Tech-Entscheidungen plötzlich trivial. Nicht weil sie unwichtig wären, sondern weil sie logisch werden. React oder Vue? Wenn das Team Vue kann, der Projekt-Zeitplan eng ist und die Anforderungen in beide Richtungen erfüllbar sind – dann ist Vue die Antwort. Ende der Diskussion.
Wann Tech-Diskussionen Sinn ergeben
Ich will nicht den Eindruck erwecken, dass technische Tiefe irrelevant ist. Sie ist es nicht. Es gibt legitime Gründe, tief in Framework-Unterschiede einzutauchen: Performance-kritische Anwendungen, spezifische Ökosystem-Abhängigkeiten, langfristige Wartbarkeit bei großen Teams.
Aber das sind keine Meinungs-Diskussionen. Das sind Analysen mit konkreten Anforderungen als Ausgangspunkt. Der Unterschied ist fundamental.
Tech-Ego ist, wenn du React verteidigst, weil du React kennst. Tech-Kompetenz ist, wenn du React wählst, weil es für diesen spezifischen Use Case die bessere Wahl ist – und du erklären kannst warum.
Die eigentliche Frage
Optimiert ihr noch Frameworks? Oder trefft ihr schon Entscheidungen?
Der Unterschied zwischen einem guten Entwickler und einem guten Tech-Lead liegt nicht im Framework-Wissen. Es liegt in der Fähigkeit, technische Entscheidungen aus Business-Anforderungen abzuleiten – und dann das richtige Werkzeug für die Aufgabe zu wählen, nicht das vertrauteste.
Frameworks kommen und gehen. React war neu, Vue war neu, Svelte ist neu. In zehn Jahren werden andere Tools diese Diskussionen dominieren. Was bleibt, ist die Fähigkeit, die richtigen Fragen zu stellen – bevor die Diskussion anfängt.
Kommentare