Vorsicht, versteckte Kosten: Wenn Software nur technisch gedacht wird

Es gibt ein Muster, das sich durch viele Lebensbereiche zieht: Wer kurzfristig spart, zahlt in der Regel langfristig drauf. Wer die Inspektion des Autos überspringt, steht irgendwann mit einem kapitalen Motorschaden da. Wer auf die Beratung durch eine Fachkraft verzichtet, macht Fehler, die teurer werden als das eingesparte Honorar. Oder, wie mein Schwiegervater zu sagen pflegt: „Wer das billige Werkzeug kauft, kauft zweimal.“ Dieses Prinzip ist so alt wie das Wirtschaften selbst, und die meisten Menschen würden ihm vermutlich sofort zustimmen.

In der Softwareentwicklung existiert eine Variante dieses Musters, die erstaunlich selten als solche erkannt wird: der Verzicht auf ein fundiertes fachliches Konzept zu Projektbeginn. In früheren Blogposts habe ich bereits darüber geschrieben, warum so viele Softwareprojekte scheitern, warum der wahre Engpass nie das Coden war und wie ein bewusst verlangsamter Prozess am Ende schneller ans Ziel führt. Heute geht es um eine Frage, die bislang zu kurz kam: Was kostet es eigentlich konkret, wenn die Fachlichkeit übersprungen wird? Und warum wird diese Rechnung in Zeiten von KI nicht besser, sondern schlechter?

Die Ungeduld am Anfang

Am Beginn eines Softwareprojekts herrscht in der Regel eine verständliche Ungeduld. Das Budget ist bewilligt, das Team steht bereit, die Erwartungen sind hoch. Die Argumentation, die ich in solchen Situationen immer wieder höre, klingt ungefähr so:

„Entwicklung ist teuer und dauert lange. Jeder Tag, an dem nicht programmiert wird, ist ein verlorener Tag. Also müssen wir so schnell wie möglich anfangen.“

Was auf den ersten Blick nach wirtschaftlicher Vernunft klingt, ist bei genauerer Betrachtung das Gegenteil.

Denn „schnell anfangen“ bedeutet in diesem Kontext fast immer, dass man die Phase überspringt, in der man herausfindet, was die Software eigentlich leisten soll. Es wird nicht die Zeit investiert, die Fachlichkeit zu erarbeiten, die Prozesse zu verstehen, die Anforderungen zu hinterfragen. Stattdessen wird sofort mit der technischen Umsetzung begonnen, weil das nach Fortschritt aussieht. Code entsteht, Commits füllen das Repository, Tickets werden abgearbeitet. Alles wirkt produktiv. Aber Produktivität und Fortschritt sind nicht dasselbe.

Fachlichkeit wird in dieser Logik nicht als Investition verstanden, sondern als Bremse. Als etwas, das die Umsetzung verzögert und das man im Laufe des Projekts nebenbei mitnehmen kann. Ich habe diesen Irrtum in unzähligen Projekten beobachtet, und er ist einer der teuersten, den ein Unternehmen begehen kann. Denn wie ich bereits an anderer Stelle argumentiert habe: Der wahre Engpass in der Softwareentwicklung war nie die Geschwindigkeit, mit der Code entsteht. Er war immer die Geschwindigkeit, mit der Verständnis entsteht. Wer das Verstehen überspringt, um schneller zu bauen, baut nicht schneller. Er baut nur früher das Falsche.

Implizite Annahmen statt expliziter Anforderungen

Wenn die Fachlichkeit nicht systematisch erarbeitet wird, entsteht kein Vakuum. Es entsteht etwas Schlimmeres: eine Sammlung impliziter Annahmen, die niemand als solche erkennt. Jede Entwicklerin und jeder Entwickler hat eine Vorstellung davon, was die Software tun soll. Jede Produktmanagerin und jeder Produktmanager hat ein Bild im Kopf. Jede Stakeholderin und jeder Stakeholder hat Erwartungen. Das Problem ist, dass diese Vorstellungen, Bilder und Erwartungen selten deckungsgleich sind.

Zu Beginn fällt das nicht auf. Alle verwenden die mehr oder weniger gleichen Begriffe und nicken regelmäßig einvernehmlich. Doch unter der Oberfläche verbergen sich unterschiedliche Interpretationen, die erst sichtbar werden, wenn Code existiert und jemand feststellt, dass das Ergebnis nicht dem entspricht, was sie oder er sich vorgestellt hat.

Ein Beispiel aus der Praxis: Ein Team entwickelt eine Software für die Auftragsabwicklung. Alle reden von „Bestellungen“, aber niemand klärt, was eine Bestellung im fachlichen Sinne eigentlich ist. Für die eine Abteilung ist eine Bestellung ein verbindlicher Kaufvertrag, für die andere ein unverbindlicher Wunschzettel, der erst durch eine Freigabe zum Auftrag wird. Das Entwicklungsteam implementiert eine dritte Variante, die keiner der beiden Sichtweisen entspricht. Erst Monate oder im schlimmsten Fall Jahre später, beim ersten Test mit echten Anwenderinnen und Anwendern, bricht das Ganze zusammen. Die Architektur trägt die tatsächliche Komplexität nicht, weil sie auf einem Verständnis aufgebaut wurde, das niemand überprüft hat.

Dann ist die Überraschung groß, und dann beginnt die Suche nach dem Schuldigen. Aber es gibt keinen Schuldigen. Es gibt nur das Fehlen eines gemeinsamen Verständnisses.

Diese impliziten Annahmen werden in Code gegossen und damit zementiert. Jede Architekturentscheidung, jede Datenstruktur, jede Schnittstelle spiegelt das Verständnis wider, das zum Zeitpunkt der Implementierung vorhanden war. War dieses Verständnis lückenhaft oder falsch, ist es die Software auch. Und je mehr Code auf einem falschen Fundament aufbaut, desto schwieriger wird es, die Richtung zu korrigieren. Ich habe dieses Phänomen bereits in einem Blogpost darüber, dass 75 Prozent aller Softwareprojekte scheitern, ausführlich beschrieben. Die Ursache ist fast nie technischer Natur. Sie liegt in der Kluft zwischen dem, was gebaut wurde, und dem, was gebraucht wird.

Die versteckte Rechnung

An dieser Stelle wird es ökonomisch interessant. Denn die Kosten, die durch fehlende Fachlichkeit entstehen, sind zum größten Teil unsichtbar. Was Unternehmen sehen, sind Budgetüberschreitungen und Verzögerungen. Was sie nicht sehen, ist ungleich teurer.

Da ist zunächst die Software, die am Zweck vorbeigeht. Sie funktioniert, sie macht etwas – aber sie löst nicht das Problem, für das sie gebaut wurde. Sie bildet Prozesse ab, die so in der Realität nicht existieren, oder sie bildet sie so ab, dass die Anwenderinnen und Anwender sie umständlich in ihren Alltag integrieren müssen, anstatt von ihnen unterstützt zu werden. Der wirtschaftliche Schaden, der dadurch entsteht, taucht in keiner Projektbilanz auf. Er verteilt sich über Jahre, in Form von Ineffizienz, Workarounds und verpassten Chancen.

Da ist die Nacharbeit, die nicht als Nacharbeit erkannt wird. Wenn ein Team Features überarbeitet, die auf falschen Annahmen basierten, wird das im Backlog als Weiterentwicklung geführt, nicht als Korrektur eines Versäumnisses. Die Stunden fließen in Bugfixes, in Anpassungen, in jene unzähligen kleinen Änderungen, die notwendig werden, weil die ursprüngliche Konzeption nicht tragfähig war. Niemand aggregiert diese Stunden und fragt:

„Wie viel davon wäre vermeidbar gewesen, wenn wir am Anfang zwei Wochen in die Fachlichkeit investiert hätten?“

Und da sind die Architekturentscheidungen, die auf einem falschen Verständnis der Domäne basieren. Eine Datenstruktur, die am tatsächlichen Geschäftsprozess vorbeigeht. Eine Trennung von Modulen, die fachlich zusammengehören. Eine Vereinfachung, die einen Sonderfall ignoriert, der sich später als der Regelfall herausstellt. Solche Entscheidungen lassen sich nachträglich entweder nur mit enormem Aufwand korrigieren oder, was häufiger vorkommt, gar nicht mehr. Sie werden zum Bestandteil der Software, und alles, was darauf aufbaut, erbt ihre Schieflage.

In Slow is smooth and smooth is fast habe ich beschrieben, wie ein bewusst verlangsamtes Vorgehen genau diese Korrekturschleifen eliminiert. Was dort an Nacharbeit wegfiel, fällt in den meisten Projekten eben nicht weg. Und das hat einen Preis, der sich über die gesamte Lebensdauer der Software akkumuliert.

Die eigentliche Tragik besteht darin, dass diese versteckten Kosten selten jemand aufaddiert. Es gibt keine Zeile im Budget, die „Kosten durch fehlendes fachliches Verständnis“ heißt. Stattdessen verteilen sie sich auf hunderte Tickets, auf Dutzende Meetings, auf unzählige Stunden, in denen kluge Menschen Probleme lösen, die bei einem besseren Fundament gar nicht erst entstanden wären. Die Rechnung wird nie gestellt, also wird sie auch nie bezahlt. Zumindest nicht bewusst.

KI als Beschleuniger des Problems

In diese Situation hinein trifft nun das Versprechen der KI-gestützten Softwareentwicklung. Die Verheißung klingt verlockend: weniger Entwicklerinnen und Entwickler, schnellere Umsetzung, niedrigere Kosten. KI-Tools generieren Code in Sekunden, der früher Stunden gedauert hätte. Ganze Prototypen entstehen über Nacht. Die Botschaft, die viele Entscheiderinnen und Entscheider daraus ableiten, lautet: Softwareentwicklung wird billiger und schneller. Also können wir mit weniger Aufwand mehr erreichen.

Das stimmt, aber nur unter einer Voraussetzung: Man muss wissen, was man bauen will. Und genau hier liegt das Problem. KI beschleunigt die Umsetzung, aber sie ersetzt nicht das Verstehen. Eine KI kann beeindruckend schnell Code produzieren, aber sie kann nicht wissen, ob dieser Code das richtige Problem löst. Sie kann eine Schnittstelle implementieren, aber nicht beurteilen, ob diese Schnittstelle den tatsächlichen Geschäftsprozess sinnvoll abbildet. Sie kann Tests generieren, aber nicht entscheiden, welche fachlichen Szenarien wirklich kritisch sind.

Wer nicht weiß, was gebraucht wird, produziert mit KI lediglich schneller Code, der am Ziel vorbeigeht. Man erhält in kürzerer Zeit mehr Software, die nicht das tut, was sie tun sollte. Das ist keine Produktivitätssteigerung. Das ist eine Beschleunigung der Wertvernichtung.

Das Muster ist dabei nicht neu. Dieselbe Verheißung gab es bereits bei Low-Code- und No-Code-Plattformen, bei RAD-Systemen, bei CASE-Tools: Jede Generation hatte ihre Technologie, die das Programmieren so einfach und schnell machen sollte, dass der Engpass verschwindet. Keine dieser Technologien hat das fundamentale Problem gelöst, weil keine von ihnen das Verstehen automatisieren konnte. KI ist leistungsfähiger als alles, was davor kam, aber auch sie kann nicht wissen, was ein Unternehmen braucht, wenn es das selbst nicht weiß.

Doch es kommt noch ein zweiter Effekt hinzu, der vielleicht noch gefährlicher ist: Die scheinbare Kostenersparnis durch KI senkt die Hemmschwelle, ohne fachliches Konzept loszulegen. Wenn Code fast nichts mehr kostet, warum dann Zeit mit der Konzeption verbringen? Wenn ein Prototyp in einem Nachmittag entsteht, warum vorher wochenlang die Fachlichkeit durchdringen? Die Argumentation klingt bestechend, aber sie übersieht, dass die Kosten der Software nur zu einem kleinen Teil im Schreiben des Codes liegen. Der weitaus größere Anteil entfällt auf alles, was danach kommt: Wartung, Anpassung, Korrektur, Integration, Schulung, Betrieb.

KI verändert also die Kostenstruktur der Codeerzeugung, aber nicht die Kostenstruktur der Softwareentwicklung als Ganzes. Und sie verschiebt den Fokus noch weiter in Richtung Technologie und noch weiter weg von der Fachlichkeit. Das ist das Gegenteil dessen, was notwendig wäre. Die versteckten Kosten werden nicht kleiner, sie werden größer. Nur fällt das nicht auf, weil die sichtbare Seite der Rechnung so viel günstiger aussieht.

Es gibt eine Parallele, die das verdeutlicht: Stellen Sie sich vor, jemand baut Häuser und bekommt plötzlich ein Werkzeug, mit dem er Wände zehnmal schneller hochziehen kann. Großartig, wenn der Bauplan stimmt. Aber wenn der Bauplan falsch ist, entstehen jetzt einfach nur schneller Häuser, die am Bedarf der Bewohnerinnen und Bewohner vorbeigehen. Der Abriss und Neubau wird nicht billiger, nur weil das Mauern schneller ging. Im Gegenteil: Weil das Bauen so billig erscheint, wird häufiger ohne Plan losgelegt, und die Gesamtkosten steigen.

Fachlichkeit ist keine Bremse, sondern eine Investition

Meine Argumentation lässt sich unterm Strich auf eine einfache Formel bringen: Fachlichkeit am Anfang eines Projekts ist kein Kostenfaktor. Sie ist eine Investition mit einem messbaren, wenn auch selten gemessenen Return. Jeder Tag, der in das Verstehen der Domäne fließt, in das Hinterfragen von Annahmen, in den Aufbau eines gemeinsamen Verständnisses, spart am Ende ein Vielfaches an Korrektur, Nacharbeit und verfehlter Software.

Das ist keine abstrakte Behauptung. Es ist die Quintessenz aus zahllosen Projekten, die ich in über zwei Jahrzehnten erlebt und begleitet habe. Die Projekte, die am Anfang in Fachlichkeit investiert haben, kamen am Ende schneller ans Ziel, kosteten weniger und lieferten bessere Ergebnisse. Die Projekte, die sofort losgelegt haben, waren schneller am Start, aber langsamer am Ziel. Oft erreichten sie das Ziel gar nicht, zumindest nicht das ursprünglich beabsichtigte.

Das Paradoxe daran: Die Investition in Fachlichkeit muss gar nicht groß sein. Oft genügen wenige Tage intensiver Gespräche mit den richtigen Menschen, um die grundlegenden Missverständnisse aufzudecken, bevor sie im Code landen. Oft reicht es, die eine entscheidende Frage zu stellen, die bislang niemand gestellt hat. Der Aufwand dafür ist verschwindend gering im Vergleich zu dem, was ein Unternehmen für die Korrektur zahlt, wenn diese Frage erst nach Monaten der Entwicklung auftaucht. Es ist, um zum Eingangsbild zurückzukehren, der Unterschied zwischen der Inspektion, die ein paar hundert Euro kostet, und dem Motorschaden, der in die Tausende geht.

Der eigentliche Engpass in der Softwareentwicklung war nie die Geschwindigkeit der Umsetzung. Er war und ist das Verständnis dessen, was überhaupt gebaut werden soll. Solange dieses Verständnis fehlt, macht schnellere Technologie nichts besser. Sie macht nur das Falsche schneller. KI ist dafür ein eindrucksvolles Beispiel, aber bei Weitem nicht das Erste.

Die versteckten Kosten fehlender Fachlichkeit werden erst sichtbar, wenn man beginnt, die Rechnung ehrlich aufzumachen. Wenn man fragt: Wie viel unserer Entwicklungszeit fließt in die Korrektur von Missverständnissen? Wie viel unserer Software löst tatsächlich das Problem, für das sie gedacht war? Wie viel unserer Architekturentscheidungen basieren auf einem fundierten Verständnis der Domäne und wie viele auf Vermutungen?

Wer sich diese Fragen stellt, wird feststellen, dass die Antworten unbequem sind. Aber sie sind der erste Schritt, um die teuerste Fehlentscheidung in der Softwareentwicklung zu vermeiden: den Verzicht auf das Fundament, auf dem alles andere steht.

(rme)