Softwareentwicklung gilt als langsam. Deshalb suchen Unternehmen ständig nach Wegen, sie zu beschleunigen: mehr Entwicklerinnen und Entwickler, bessere Tools, effizientere Prozesse. Neuerdings verspricht KI, das Schreiben von Code drastisch zu verkürzen. Aber was, wenn der Engpass nie das Schreiben war?

Ich beobachte seit Jahren, wie Unternehmen in die Beschleunigung an der falschen Stelle investieren. Sie optimieren das Coden, während das eigentliche Problem ungelöst bleibt: das Verstehen dessen, was überhaupt gebaut werden soll. In diesem Artikel geht es darum, wo der wahre Engpass liegt, und was es kostet, ihn zu ignorieren.

Die These ist einfach: Der Flaschenhals in der Softwareentwicklung war nie die Geschwindigkeit, mit der Code entsteht. Er war immer die Geschwindigkeit, mit der Verständnis entsteht. Wer das eine optimiert und das andere vernachlässigt, beschleunigt in die falsche Richtung.

Der Mythos vom langsamen Coden

Es gibt eine stillschweigende Annahme in vielen Unternehmen: Softwareentwicklung dauert so lange, weil das Programmieren so aufwendig ist. Je schneller Code entsteht, desto schneller ist das Produkt fertig. Diese Annahme klingt plausibel, aber sie hält einer näheren Betrachtung nicht stand.

Fragen Sie eine erfahrene Entwicklerin, womit sie ihre Zeit verbringt. Die Antwort wird Sie vielleicht überraschen. Das eigentliche Schreiben von Code macht oft nur einen Bruchteil der Arbeit aus. Der größere Teil entfällt auf anderes: Sie muss herausfinden, was genau überhaupt gebaut werden soll. Verstehen, wie das bestehende System funktioniert. Klären, was die Anforderung wirklich meint. Korrigieren, was beim ersten Mal nicht richtig verstanden wurde.

Das ist keine Ineffizienz. Das ist die Natur der Arbeit. Software zu entwickeln bedeutet, ein Problem zu verstehen und dieses Verständnis in eine formale Sprache zu übersetzen, die ein Computer ausführen kann. Der Übersetzungsschritt, das Coden, ist dabei der kleinere Teil. Der größere Teil ist das Verstehen selbst.

Die Zeit zwischen Anforderung und fertigem Feature ist nicht deshalb lang, weil Tippen langsam wäre. Sie ist lang, weil Verstehen Zeit braucht. Weil Kommunikation Zeit braucht. Weil das Übersetzen zwischen der Welt der Fachlichkeit und der Welt des Codes Zeit braucht. Wer diesen Unterschied nicht sieht, investiert in die falsche Stelle.

Es gibt eine Analogie aus dem Schreiben: Niemand würde behaupten, dass ein Roman langsam entsteht, weil der Autor langsam tippt. Ein Roman entsteht langsam, weil das Entwickeln der Geschichte, der Charaktere, der Struktur Zeit braucht. Das Tippen am Ende ist trivial. Bei Software ist es nicht anders. Nur lassen wir uns von der scheinbaren Komplexität des Codes blenden.

Das Falsche schneller bauen

Was passiert nun, wenn man den Engpass falsch diagnostiziert? Man optimiert das, was man für das Problem hält, und wundert sich, warum die Ergebnisse ausbleiben.

Ich habe Unternehmen erlebt, die ihre Teams vergrößert haben, um schneller zu werden. Und das Ergebnis war nicht mehr Output, sondern mehr Koordinationsaufwand. Plötzlich mussten mehr Menschen auf den gleichen Stand gebracht werden. Mehr Meetings, mehr Abstimmungen, mehr Missverständnisse. Das berühmte Gesetz von Frederick P. Brooks („Adding manpower to a late software project makes it later“) ist keine theoretische Spielerei. Es beschreibt, was passiert, wenn man glaubt, Software entstehe primär durch Arbeitskraft.

Ich habe auch Unternehmen erlebt, die auf neue Frameworks umgestiegen sind, weil die alten angeblich zu langsam waren. Das Ergebnis war nicht eine schnellere Entwicklung, sondern eine Lernkurve, die Monate gekostet hat. Die versprochene Produktivitätssteigerung kam nie an, weil das eigentliche Problem, nämlich das fehlende Verständnis der Fachlichkeit, durch das neue Framework nicht gelöst wurde. Es wurde nur verschoben, auf eine neue technische Ebene.

Aktuell erlebe ich Unternehmen, die sich von KI-gestützten Coding-Assistenten eine dramatische Produktivitätssteigerung versprechen. Diese Tools sind beeindruckend. Sie können Code generieren, Boilerplate reduzieren, Vorschläge machen. Sie können in Sekunden produzieren, wofür ein Mensch Minuten oder Stunden bräuchte. Aber sie lösen nicht das Problem, das die meisten Projekte tatsächlich ausbremst.

Die Erwartungen an KI in der Softwareentwicklung sind derzeit enorm. Von zehnfacher Produktivitätssteigerung ist die Rede, von der Demokratisierung des Programmierens, davon, dass bald jeder Software entwickeln könne. Manche prophezeien gar das Ende des klassischen Entwicklerberufs. Diese Narrative haben eines gemeinsam: Sie gehen davon aus, dass das Schreiben von Code der limitierende Faktor ist. Wenn KI das Schreiben übernimmt, so die Logik, dann verschwinden die Engpässe.

Geschichte wiederholt sich

Wer länger in dieser Branche arbeitet, erkennt das Muster. Die gleichen Versprechen gab es schon bei Low-Code- und No-Code-Plattformen: Fachabteilungen sollten ihre Software selbst bauen, Entwicklerinnen und Entwickler würden überflüssig. Davor waren es die RAD-Systeme (Rapid Application Development), die das Programmieren so einfach machen sollten, dass es jeder könnte. Davor CASE-Tools, davor 4GL-Sprachen. Jede Generation hatte ihre Technologie, die angeblich das Ende der klassischen Softwareentwicklung einläuten würde. Keine dieser Vorhersagen hat sich bewahrheitet.

Das bedeutet nicht, dass diese Technologien nutzlos gewesen wären. Viele haben die Arbeit tatsächlich erleichtert, bestimmte Aufgaben beschleunigt, neue Möglichkeiten eröffnet. Aber sie haben das grundlegende Problem nicht gelöst: Jemand muss verstehen, was gebaut werden soll. Irgendjemand muss die Brücke schlagen zwischen dem, was der Kunde braucht, und dem, was die Maschine ausführen kann. Diese Übersetzungsleistung lässt sich nicht wegautomatisieren.

Auch KI wird daran nichts ändern. Entwicklerinnen und Entwickler werden weiterhin gebraucht. Aber was sich ändert, ist das Anforderungsprofil. Reines „Ich kann programmieren“ reicht nicht mehr aus. Die Fähigkeit, Code zu schreiben, wird zur Commodity, wenn Maschinen das ebenfalls können. Was bleibt, was an Wert gewinnt, ist die Fähigkeit zu verstehen: Probleme zu durchdringen, die richtigen Fragen zu stellen, zwischen Fachlichkeit und Technik zu übersetzen. Die Zukunft gehört nicht denen, die am schnellsten Code produzieren, sondern denen, die am besten verstehen, welcher Code überhaupt gebraucht wird.

Denn eine KI kann auf Anweisung Code produzieren. Aber die Anweisung muss von einem Menschen kommen, der verstanden hat, was gebaut werden soll. Die KI kann nicht wissen, was der Kunde braucht. Sie kann nicht die impliziten Annahmen hinterfragen, die in einer Anforderung stecken. Sie kann nicht erkennen, dass zwei Stakeholder unterschiedliche Dinge meinen, wenn sie das gleiche Wort verwenden. All das bleibt menschliche Arbeit.

Die Illusion der KI-generierten Produktivität

Was passiert, wenn Unternehmen diese Arbeit überspringen und stattdessen auf KI-generierte Produktivität setzen? Sie bekommen mehr Code in kürzerer Zeit. Code, der auf ungeprüften Annahmen basiert. Code, der Missverständnisse in Maschinensprache übersetzt. Code, der später aufwendig korrigiert oder ersetzt werden muss. Die KI hat geliefert, was sie sollte. Nur war es nicht das, was gebraucht wurde.

Wenn ich nicht verstanden habe, was ich bauen soll, hilft es mir wenig, es schneller zu bauen. Ich baue dann nur das Falsche effizienter. Der Code entsteht schneller, aber er löst nicht das richtige Problem. Die Iteration kommt trotzdem, nur dass jetzt mehr Code da ist, der wieder angefasst werden muss. Mehr Code bedeutet mehr Komplexität, mehr Stellen, die angepasst werden müssen, mehr Potenzial für Fehler.

Das soll nicht heißen, dass KI-Tools nutzlos wären. Im Gegenteil: Für erfahrene Entwicklerinnen und Entwickler, die genau wissen, was sie brauchen, können sie wertvolle Werkzeuge sein. Sie können Routinearbeiten abnehmen und Raum schaffen für die Arbeit, die wirklich zählt: das Verstehen, das Hinterfragen, das Durchdenken. Aber sie ersetzen diese Arbeit nicht. Wer glaubt, mit KI die Phase des Verstehens überspringen zu können, wird am Ende mehr Zeit verlieren, nicht weniger.

KI beschleunigt das Schreiben. Sie beschleunigt nicht das Verstehen. Und das Verstehen war schon immer der eigentliche Engpass. Ein Werkzeug, das mir hilft, schneller in die falsche Richtung zu laufen, ist kein Produktivitätsgewinn. Es ist eine Beschleunigung des Scheiterns.

Wo die Zeit wirklich verloren geht

Um die Frage auf den Punkt zu bringen: Wo genau verlieren Projekte ihre Zeit?

Der erste Faktor sind Missverständnisse zwischen Fachbereich und Entwicklung. Eine Anforderung wird formuliert, die Entwicklung setzt sie um, und bei der Abnahme stellt sich heraus: Das war nicht gemeint. Nicht, weil jemand einen Fehler gemacht hätte. Sondern, weil die gleichen Worte für verschiedene Menschen verschiedene Dinge bedeuten.

Die Fachexpertin spricht von einem „Auftrag“ und meint damit etwas Bestimmtes, mit all den impliziten Regeln, Ausnahmen und Randbedingungen, die sie aus ihrer täglichen Arbeit kennt. Der Entwickler hört „Auftrag“ und bildet das auf sein mentales Modell ab, das notwendigerweise unvollständig ist. Beide glauben, sie reden über dasselbe. Beide merken erst, wenn Code existiert, dass dem nicht so war.

Software spiegelt am Ende nicht das wider, was der Kunde haben will, und erst recht nicht das, was er braucht: Software spiegelt vielmehr das wider, was die Entwicklerinnen und Entwickler verstanden haben. Dabei spielen implizite Annahmen und Interpretationen eine Rolle, und die sind – naturgemäß – oft falsch. Das ist kein Vorwurf an die Beteiligten. Es ist die unvermeidliche Konsequenz davon, dass Wissen nicht einfach von einem Kopf in den anderen fließt.

Und dann ist die Korrektur teuer. Nicht weil Coden teuer wäre, sondern weil das Verstehen nachgeholt werden muss, während gleichzeitig bestehender Code angepasst wird.

Der zweite Faktor sind Annahmen, die sich als falsch herausstellen. Jedes Projekt beginnt mit impliziten Annahmen über das Problem, über die Nutzerinnen und Nutzer, über die Randbedingungen. Manche dieser Annahmen sind richtig, manche nicht. Das Problem: Die meisten dieser Annahmen werden nie explizit gemacht. Sie existieren in den Köpfen der Beteiligten, unausgesprochen und ungeprüft.

Und je später eine falsche Annahme erkannt wird, desto teurer wird die Korrektur. Eine Annahme, die in der ersten Woche hinterfragt wird, kostet ein Gespräch. Eine Annahme, die nach sechs Monaten Entwicklung zutage tritt, erfordert einen Rewrite. Nicht selten stellt sich heraus, dass ein Feature, an dem monatelang gearbeitet wurde, auf einer grundlegend falschen Annahme basierte und nun entweder komplett neu gedacht oder ersatzlos gestrichen werden muss.

Der dritte Faktor sind Iterationen, die aus fehlendem Verständnis entstehen. Ich meine nicht die guten Iterationen, also das schrittweise Verfeinern eines Produkts basierend auf echtem Feedback. Diese Iterationen sind wertvoll. Ich meine die unnötigen Iterationen: etwas bauen, feststellen dass es falsch ist, neu bauen. Nicht weil sich die Anforderungen geändert hätten, sondern weil sie von Anfang an nicht richtig verstanden wurden.

Diese Art von Iteration ist teuer. Sie kostet nicht nur die Zeit für den Rewrite selbst, sondern auch die Motivation des Teams, das seine Arbeit verworfen sieht. Sie kostet das Vertrauen der Stakeholder, die sich fragen, warum so lange an etwas gearbeitet wurde, das am Ende nicht brauchbar ist. Sie kostet die Gelegenheit, in dieser Zeit etwas Sinnvolles zu bauen.

All diese Faktoren haben eines gemeinsam: Sie entstehen nicht beim Coden. Sie entstehen davor. Oder genauer: Sie entstehen, weil das Davor zu kurz kam.

Erst verstehen, dann bauen

Amazon hat ein Prinzip, das „Working Backwards“ heißt. Die Idee: Bevor ein Produkt entwickelt wird, schreibt das Team die Pressemitteilung für das fertige Produkt. Nicht als Marketing-Übung, sondern als Denkwerkzeug. Die Pressemitteilung zwingt dazu, vom Ergebnis her zu denken. Was genau soll dieses Produkt für wen lösen? Warum sollte es jemanden interessieren? Welches Problem adressiert es? Und vor allem: Wie würde ein Kunde beschreiben, warum dieses Produkt sein Leben verbessert?

Das klingt nach zusätzlichem Aufwand. Es ist zusätzlicher Aufwand, am Anfang. Aber dieser Aufwand spart ein Vielfaches an Zeit später, weil er Missverständnisse aufdeckt, bevor sie in Code gegossen werden. Er zwingt dazu, Annahmen explizit zu machen. Er schafft ein gemeinsames Verständnis, bevor die erste Zeile Code geschrieben wird. Und er verhindert, dass Monate in ein Produkt fließen, das am Ende niemand braucht.

Die Werkzeuge dafür müssen nicht ausgefallen sein. Intensive Gespräche mit Fachleuten, bei denen wirklich zugehört wird, nicht nur, um Anforderungen aufzunehmen, sondern um das Problem zu verstehen. Workshops, in denen gemeinsam Prozesse durchgespielt werden, um zu sehen, wo die Komplexität wirklich liegt. Visualisierungen, die zeigen, wie verschiedene Beteiligte das Problem verstehen, und wo ihre mentalen Modelle auseinandergehen.

Es gibt formalisierte Methoden wie Event Storming, bei dem Fachleute und Entwicklerinnen und Entwickler gemeinsam den Ablauf von Geschäftsprozessen auf Post-its an der Wand durchspielen. Es gibt die strategischen Muster aus Domain-Driven Design (DDD), die dabei helfen, große Domänen in handhabbare Teile zu zerlegen. Diese und ähnliche Methoden können hilfreich sein, aber sie sind kein Selbstzweck. Man kann auch ohne sie gute Ergebnisse erzielen, wenn die Grundhaltung stimmt.

Denn das Wichtigste ist nicht die Methode, sondern die Bereitschaft, Zeit für Verständnis zu investieren, bevor der erste Commit entsteht. Die Bereitschaft, Fragen zu stellen, die vielleicht dumm klingen. Die Bereitschaft, Annahmen zu hinterfragen, auch wenn alle anderen sie für selbstverständlich halten. Die Bereitschaft, langsamer zu beginnen, um schneller ans Ziel zu kommen.

„Wir werden langsamer anfangen, damit wir schneller fertig werden“ klingt paradox. Aber es ist die Realität, die ich in Projekt nach Projekt beobachte. Die Projekte, die sich am Anfang Zeit nehmen, kommen am Ende schneller ans Ziel. Die Projekte, die sofort losrennen, verlieren sich in Sackgassen.

Der unterschätzte ROI von Verständnis

Die Investition in Problemverständnis hat einen Return on Investment (ROI). Er ist nur schwerer zu messen als die Kosten eines zusätzlichen Entwicklers oder die Lizenzgebühren eines Tools.

Dieser ROI zeigt sich in dem, was nicht passiert: Rewrites, die nicht nötig werden. Iterationen, die überflüssig sind. Missverständnisse, die nicht erst in der Produktion sichtbar werden. Features, die nicht gebaut werden, weil sich früh herausstellt, dass sie das eigentliche Problem gar nicht lösen würden. Architekturentscheidungen, die nicht revidiert werden müssen, weil sie von Anfang an auf einem soliden Verständnis basierten.

Er zeigt sich auch in dem, was passiert: Software, die das fachliche Problem tatsächlich löst – beim ersten Mal, nicht nach drei Iterationen. Teams, die das Warum verstehen und deshalb bessere Entscheidungen treffen können, auch ohne explizite Anweisungen. Architekturentscheidungen, die länger tragen, weil sie auf einem soliden Verständnis der Domäne basieren statt auf Vermutungen.

Das ist schwer zu verkaufen. Niemand bekommt einen Bonus für Fehler, die nicht passiert sind. Niemand wird befördert, weil ein Projekt ohne Umwege verlief. Die Erfolge des Verstehens sind unsichtbar. Sie manifestieren sich in der Abwesenheit von Problemen, nicht in der Anwesenheit von Lösungen. Das macht sie leicht zu übersehen und schwer zu würdigen.

Aber die Rechnung ist eindeutig: Die Zeit, die am Anfang in Verständnis fließt, kommt am Ende mehrfach zurück. Ein Tag, der in ein gutes Gespräch mit Fachleuten investiert wird, kann Wochen an Rewrite sparen. Ein Workshop, der Annahmen aufdeckt, kann verhindern, dass monatelang in die falsche Richtung entwickelt wird. Eine Frage, die zu Beginn gestellt wird, kann ein ganzes Projekt vor dem Scheitern bewahren.

Das bedeutet nicht, dass man Monate mit Analyse verbringen soll, bevor man anfängt. Es bedeutet, dass man die richtigen Fragen stellt, bevor man die Antworten in Code gießt. Es bedeutet, dass man zuhört, bevor man baut. Es bedeutet, dass man Verständnis als Teil der Arbeit begreift, nicht als Verzögerung.

Der wahre Engpass verdient Aufmerksamkeit

Softwareentwicklung ist nicht langsam, weil Programmieren langsam wäre. Sie ist langsam, weil Verstehen Zeit braucht – und weil wir diese Zeit oft nicht einräumen. Wir beschleunigen das Schreiben von Code, während der wahre Engpass unbeachtet bleibt.

Das ist kein Vorwurf an einzelne Personen. Der Druck, schnell Ergebnisse zu liefern, ist real. Die Ungeduld des Managements, das sichtbaren Fortschritt sehen will, ist verständlich. Code ist sichtbar; Verständnis ist es nicht. Es ist menschlich, das Sichtbare zu optimieren. Aber es ist auch kurzsichtig.

Die gute Nachricht: Dieser Engpass lässt sich adressieren. Nicht durch schnellere Tools, sondern durch die Bereitschaft, am Anfang eines Projekts in Verständnis zu investieren. Durch Gespräche mit Fachleuten, durch gemeinsames Durchdenken des Problems, durch das Aufdecken von Annahmen, bevor sie in Code gegossen werden. Durch die Einsicht, dass der schnellste Weg zum Ziel nicht immer der ist, der am schnellsten beginnt.

Das kostet Zeit. Es kostet aber weniger Zeit als die Alternative. Und es führt zu Software, die ihren Namen verdient: Software, die Probleme löst, statt neue zu schaffen.

Der wahre Engpass in der Softwareentwicklung ist nicht das Coden. Er war es nie. Wer das erkennt, hat den ersten Schritt gemacht, um schneller ans Ziel zu kommen – indem er langsamer anfängt. Ganz getreu dem berühmten Motto der Navy SEALs: „Slow is smooth and smooth is fast.“

(rme)