Wir entwickeln Software nicht, weil es so schön ist. Wir entwickeln sie, um fachliche Probleme zu lösen. Diese Unterscheidung klingt banal, aber sie geht in der täglichen Arbeit vieler Teams verloren. Ich beobachte seit Jahren, wie Diskussionen in Entwicklungsteams ablaufen: Es geht um Frameworks, um Architekturstile, um die neueste Technologie. Es geht darum, ob man besser auf Microservices oder auf einen Modulithen setzt, ob man dieses oder jenes Tool verwendet, ob die Code-Coverage hoch genug ist. Worüber erstaunlich selten gesprochen wird: das fachliche Problem, das die Software eigentlich lösen soll.

Das ist kein Zufall und keine Nachlässigkeit. Es ist ein strukturelles Problem unserer Branche. Wir haben uns so sehr an technische Debatten gewöhnt, dass wir gar nicht mehr merken, wie weit wir uns von der eigentlichen Aufgabe entfernt haben. Dieser Artikel ist ein Versuch, das sichtbar zu machen – und ein Plädoyer dafür, den Blick wieder auf das Wesentliche zu richten.

Der Technologie-Tunnelblick

Warum reden wir lieber über Technologie als über Fachlichkeit? Die Antwort ist unbequem, aber nachvollziehbar: Technologie ist greifbar. Sie lässt sich vergleichen, messen, bewerten. Man kann Benchmarks lesen, Dokumentationen studieren, Tutorials durcharbeiten. All das passiert in einer Welt, die Entwicklerinnen und Entwickler kennen und kontrollieren.

Fachliche Probleme sind anders. Sie sind oft vage formuliert, widersprüchlich, und sie erfordern Gespräche mit Menschen, die eine andere Sprache sprechen – nicht im linguistischen Sinne, sondern im Sinne von Denkweisen und Prioritäten. Eine Fachexpertin interessiert sich nicht dafür, ob das System auf Kubernetes läuft. Sie will wissen, ob es ihre Arbeit erleichtert. Das sind verschiedene Welten, und die Brücke zwischen ihnen zu bauen, ist anstrengend.

Hinzu kommt ein strukturelles Problem: Die Branche belohnt technische Expertise stärker als Domänenwissen. Wer sich mit der neuesten Technologie auskennt, gilt als kompetent. Wer die Fachdomäne einer Versicherung oder eines Logistikunternehmens versteht, wird selten auf Konferenzen eingeladen. Das prägt, worauf Entwicklerinnen und Entwickler ihre Energie richten. Und so entstehen Teams, die technisch auf der Höhe der Zeit sind, aber nicht wirklich verstehen, welches Problem sie lösen.

Architekturstile als Glaubensfragen

Nirgends zeigt sich der Technologie-Tunnelblick deutlicher als in der Debatte um Architekturstile. Nehmen Sie die Diskussion um Microservices versus Monolith. In den 2010er-Jahren galt es fast als Naturgesetz, dass Microservices die bessere Wahl sind. Wer einen Monolithen baute, musste sich rechtfertigen. Wer Microservices einsetzte, galt als modern.

Aber was ist eigentlich die fachliche Begründung für Microservices? Im Kern geht es darum, Teile eines Systems unabhängig voneinander entwickeln, deployen und skalieren zu können. Das ist sinnvoll, wenn unterschiedliche Teams an verschiedenen Teilen arbeiten, wenn diese Teile unterschiedliche Lebenszyklen haben, wenn sie unterschiedlich stark genutzt werden. Es ist weniger sinnvoll, wenn ein kleines Team ein überschaubares System baut, bei dem alles zusammenhängt.

Trotzdem entscheiden sich Teams für Microservices, ohne diese Fragen zu stellen. Die Entscheidung fällt nicht auf Basis der Domäne, sondern auf Basis dessen, was gerade als Best Practice gilt. Das Ergebnis sind verteilte Systeme mit all ihrer Komplexität (Netzwerkkommunikation, Eventual-Consistency, Debugging über Servicegrenzen hinweg, …), ohne dass diese Komplexität durch einen fachlichen Nutzen gerechtfertigt wäre.

Die Architektur sollte aus der Domäne folgen, nicht umgekehrt. Wenn das fachliche Problem eine klare Trennung von Verantwortlichkeiten nahelegt, können Microservices die richtige Antwort sein. Wenn das Problem überschaubar ist und die Teile eng zusammenhängen, ist ein gut strukturierter Monolith oft die bessere Wahl. Aber diese Abwägung findet zu selten statt. Stattdessen wird der Architekturstil zur Glaubensfrage, losgelöst von der Realität des Problems.

Prinzipien ohne Kontext

Ähnlich verhält es sich mit Design-Prinzipien. DRY, SOLID, Clean-Code: Diese Begriffe kennt jede Entwicklerin und jeder Entwickler. Sie werden in Büchern gelehrt, in Code-Reviews eingefordert, in Vorstellungsgesprächen abgefragt. Aber sie werden oft so behandelt, als wären sie universelle Gesetze, die immer und überall gelten.

Nehmen Sie DRY (Don’t Repeat Yourself). Das Prinzip besagt, dass jede Information im System nur einmal repräsentiert sein sollte. Das klingt einleuchtend. Duplikation führt zu Inkonsistenzen, erschwert Änderungen, erhöht die Fehleranfälligkeit. Soweit die Theorie.

In der Praxis führt die dogmatische Anwendung von DRY oft zu einem anderen Problem: falschen Abstraktionen. Zwei Stellen im Code sehen ähnlich aus, also werden sie zusammengefasst. Aber allzu oft sehen sie nur zufällig ähnlich aus, fachlich haben sie nichts miteinander zu tun. Doch nun sind sie gekoppelt, und wenn sich eine Stelle ändern muss, muss die Abstraktion angepasst werden, die auch die andere Stelle betrifft. Die vermeintliche Vereinfachung wird zur Komplexitätsfalle.

Die Frage, ob Duplikation akzeptabel ist, lässt sich nicht ohne fachlichen Kontext beantworten. Wenn zwei Codestellen dasselbe fachliche Konzept repräsentieren, sollten sie zusammengeführt werden. Wenn sie verschiedene Konzepte repräsentieren, die nur zufällig gleich implementiert sind, sollten sie getrennt bleiben. Aber diese Unterscheidung erfordert ein Verständnis der Domäne – und genau das fehlt oft.

Dasselbe gilt für SOLID, für Clean-Code-Regeln, für jedes Prinzip. Sie sind Heuristiken, keine Gesetze. Ihr Nutzen hängt vom Kontext ab. Eine Klasse mit mehr als 200 Zeilen ist nicht automatisch schlecht. Eine Methode mit drei Parametern ist nicht automatisch besser als eine mit fünf. Es kommt darauf an, was die Klasse oder Methode tut, welches fachliche Konzept sie repräsentiert, wie sie verwendet wird. Wer Prinzipien ohne Kontext anwendet, optimiert für technische Metriken statt für fachliche Klarheit.

Falscher Maßstab für Qualität

Apropos Metriken: Auch bei der Qualitätsmessung zeigt sich der Technologie-Tunnelblick. Test-Coverage ist das prominenteste Beispiel. Eine hohe Coverage gilt als Zeichen guter Qualität. Teams setzen sich Ziele: 80 Prozent, 90 Prozent, manchmal 100 Prozent. Tools visualisieren die Abdeckung, Dashboards zeigen Trends, Code-Reviews fordern Tests für jede neue Zeile.

Aber was misst Test-Coverage eigentlich? Sie misst, wie viel Code von Tests ausgeführt wird. Sie misst nicht, ob die richtigen Dinge getestet werden. Sie misst nicht, ob die Tests sinnvolle Szenarien abdecken. Und sie misst schon gar nicht, ob die Software das fachliche Problem löst.

Es ist möglich, 100 Prozent Coverage zu erreichen und trotzdem eine Software zu haben, die am Bedarf vorbeigeht. Die Tests prüfen, dass der Code macht, was er macht, aber niemand hat jemals geprüft, ob das, was er macht, auch das Richtige ist. Die Anforderungen waren missverstanden, die Domäne war nicht durchdrungen, die Gespräche mit den Fachexpertinnen und Fachexperten haben nicht stattgefunden. Der Code ist technisch einwandfrei und fachlich wertlos.

Ähnlich verhält es sich mit statischen Analysen, Linting-Regeln, Komplexitätsmetriken. Sie alle messen technische Eigenschaften des Codes. Sie können helfen, bestimmte Probleme zu vermeiden. Aber sie können nicht messen, was wirklich zählt: ob die Software das richtige Problem auf die richtige Weise löst. Wer sich auf diese Metriken verlässt, verwechselt technische Sauberkeit mit fachlicher Qualität.

Die Fachlichkeit zurückholen

Wie lässt sich der Fokus verschieben? Es gibt Ansätze, die dabei helfen können: Domain-Driven Design (DDD), Event-Storming, Domain-Storytelling & Co. Sie alle haben gemeinsam, dass sie die Fachlichkeit in den Mittelpunkt stellen. Sie fordern, dass Entwicklerinnen und Entwickler mit Fachexpertinnen und Fachexperten sprechen, dass der Code die Sprache der Domäne spricht, dass Architekturentscheidungen aus dem fachlichen Kontext abgeleitet werden.

Aber hier lauert eine Falle: Auch diese Ansätze können zum Selbstzweck werden. Ich habe kürzlich darüber geschrieben, wie Domain-Driven Design dieses Schicksal ereilt hat. Die Kernbeobachtung: DDD wurde akademisiert. Was als einfache Idee begann („verstehe die Domäne und sprich die Sprache des Business“) ist zu einem Katalog von Patterns geworden, über den Entwicklerinnen und Entwickler diskutieren, statt mit Fachexpertinnen und Fachexperten zu reden.

Das ist bezeichnend. Selbst ein Ansatz, der explizit den Fachfokus propagiert, wurde von uns als Branche in etwas Technisches verwandelt. Wir diskutieren, ob etwas ein Aggregat oder eine Entity ist, statt zu fragen, wie die Fachleute das Konzept nennen. Wir zeichnen Bounded-Context-Diagramme, statt die Grenzen aus der Domäne abzuleiten. Wir lernen die Patterns auswendig, statt die Domäne zu verstehen. Der Sog der Technologie ist so stark, dass er selbst Ansätze vereinnahmt, die gegen ihn gerichtet sind.

Die Lösung liegt nicht in neuen Methoden oder besseren Tools. Sie liegt in einer Haltungsänderung. Wir müssen akzeptieren, dass die schwierige Arbeit, also die Gespräche mit Fachexpertinnen und Fachexperten, das Ringen um Verständnis, das Aushalten von Unsicherheit, nicht durch Technik ersetzt werden kann. Wir müssen den Mut aufbringen, weniger über Frameworks zu reden und mehr über Probleme. Wir müssen uns eingestehen, dass technische Eleganz kein Wert an sich ist, wenn sie nicht im Dienst der Fachlichkeit steht.

Software als Werkzeug, nicht als Kunstwerk

Softwareentwicklung ist angewandte Problemlösung. Wir werden nicht dafür bezahlt, schönen Code zu schreiben. Wir werden dafür bezahlt, Probleme zu lösen. Das klingt banal, aber es hat weitreichende Konsequenzen.

Es bedeutet, dass die beste Architektur nicht die eleganteste ist, sondern die, die das fachliche Problem am besten adressiert. Es bedeutet, dass Prinzipien und Patterns Werkzeuge sind, keine Ziele. Es bedeutet, dass technische Schulden manchmal akzeptabel sind, wenn sie die schnellere Lösung eines dringenden fachlichen Problems ermöglichen. Es bedeutet, dass wir unseren Erfolg nicht an Coverage-Zahlen oder Clean-Code-Metriken messen sollten, sondern daran, ob die Software ihren Zweck erfüllt.

Das erfordert ein Umdenken. Es erfordert, dass wir unsere Komfortzone verlassen und uns auf das einlassen, was unbequem ist: die Kommunikation mit Menschen, die anders denken als wir. Es erfordert Demut, also die Einsicht, dass wir als Entwicklerinnen und Entwickler nicht die Expertinnen und Experten für die Domäne sind, auch wenn wir gerne so tun. Es erfordert Pragmatismus, also die Bereitschaft, technisch suboptimale Lösungen zu akzeptieren, wenn sie fachlich besser passen.

Ich plädiere nicht dafür, technische Qualität zu ignorieren. Guter Code ist wichtig. Saubere Architektur ist wichtig. Tests sind wichtig. Aber all das ist Mittel zum Zweck, nicht Selbstzweck. Wenn wir das vergessen, bauen wir technisch ausgefeilte Systeme, die niemand benötigt. Wir optimieren für Metriken, die nichts aussagen. Wir führen Debatten, die nichts bringen.

Die Frage, die wir uns in jedem Projekt, bei jeder Entscheidung stellen sollten, ist einfach: Hilft das, das fachliche Problem besser zu lösen? Wenn ja, machen wir weiter. Wenn nein, sollten wir innehalten und uns fragen, ob wir gerade der Technologie dienen oder der Fachlichkeit. Die Antwort darauf bestimmt, ob wir Softwareentwicklung als Handwerk betreiben oder als Selbstzweck.

(rme)