Future{hacks}: Der schleichende Notfall: Warum “läuft doch noch” dein Budget verbrennt

Es gibt Sätze, die klingen nach Pragmatismus und sind in Wahrheit eine Bankrotterklärung.

„Läuft doch noch“ ist so einer.

Weil er nicht beschreibt, wie gut ein System ist. Er beschreibt nur, dass es noch nicht laut genug kaputt ist, um Budget zu bekommen. Und genau da sitzt die Falle: Solange nichts spektakulär brennt, wirkt Ignorieren billig. In Wahrheit zahlst du jede Woche. Nur nicht als Rechnung, sondern als Kapazitätsverlust, Risiko und Stillstand.

„Läuft doch noch“ ist deshalb die teuerste Phrase, weil sie aus einem technischen Problem ein betriebswirtschaftliches macht: Du wandelst Entwicklungszeit in Reparaturzeit um, ohne es zu bemerken. Und du gewöhnst die Organisation daran, dass das normal ist.

Disclaimer: Der folgende Fall stammt aus unserem Projekt-Umfeld bei LEAN-CODERS und prägt somit meine Perspektive auf „Vendor-Versprechen vs. Lieferrealität“.

Wenn „läuft“ bedeutet, dass dein Team nicht mehr liefert

Die meisten Firmen messen Software falsch. Sie fragen: „Ist das System verfügbar?“ Oder: „Gibt’s gerade einen Incident?“ Das ist wie beim Auto nur zu prüfen, ob der Motor anspringt und zu ignorieren, dass du jede Woche in die Werkstatt musst.

Die bessere Frage lautet: Wieviel deiner bezahlten Entwicklungszeit fließt in echte Produktentwicklung und wieviel in Betrieb, Support, Bugfixing und ‚irgendwer muss das halt schnell richten‘?

Wenn du diese Aufteilung nicht kennst, steuerst du Software wie eine Blackbox. Und dann ist „läuft doch noch“ nicht nur eine Aussage, sondern eine Ausrede.

Weil du dich auf das Minimum zurückziehst: Solange es irgendwie geht, wird’s schon passen. Und genau so entstehen Legacy-Systeme, die nicht „alt“ sind, sondern wirtschaftlich gelähmt.

Der schleichende Notfall: nicht „Down“, aber handlungsunfähig

Genau dieses Muster sehen wir immer wieder bei unseren Kunden. So auch bei einer österreichischen Organisation, die eine komplexe Legacy-Plattform betreibt. Das System lief. Aber die Organisation steckte in einem Zustand, den man nur als schleichenden Notfall beschreiben kann: permanent nicht tot, aber permanent handlungsunfähig.

Der Grund war brutal einfach, denn bei unserer Analyse stellten wir fest: 89% der Zeit gingen in Operations & Support, nur 11% in echte Weiterentwicklung.

Das ist der Moment, in dem „läuft doch noch“ seine Maske verliert. Denn 89% Betrieb heißt nicht „das Team ist halt ausgelastet“. Es heißt: Du bezahlst ein Produktteam dafür, dass es Feuer löscht. Und jedes neue Feature, jede neue Anforderung, jede neue Schnittstelle landet in einem System, das schon kaum noch atmet.

Das Entscheidende: In so einem Zustand gibt es selten den einen großen Knall. Es ist nicht der spektakuläre Totalausfall, der dich aufweckt. Es ist das langsame Zähwerden, das irgendwann als Normalzustand akzeptiert wird.

Wie „läuft doch noch“ in der Realität aussieht

Es fängt harmlos an. Ein Ticket dauert halt länger. Ein Release wird halt verschoben. Eine kleine Änderung braucht plötzlich drei Leute, weil niemand mehr genau weiß, was wo hängt. Und irgendwann ist das System nicht nur technisch komplex, sondern organisatorisch toxisch: Jeder hat Angst, etwas anzufassen, weil jede Änderung Nebenwirkungen hat.

In diesem konkreten Fall haben wir das sehr deutlich gesehen:

Tickets hingen monatelang irgendwo zwischen „in progress“ und „wir kümmern uns“. Deployments passierten manuell und selten. Tests waren kein Sicherheitsnetz, sondern eine Hoffnung. Und genau das macht „läuft doch noch“ so teuer: Du zahlst nicht einmalig – du zahlst jeden Tag ein bisschen.

Dann kam das nächste typische Symptom: Die Organisation redete sich ein, sie wäre „produktgetrieben“, während sie in Wahrheit Zeit in Meetings über Dinge investierte, die später kaum genutzt wurden. Wenn Backlog-Management nicht greift, ist das Ergebnis fast immer gleich: Feature-Wildwuchs. Und Feature-Wildwuchs ist nicht nur ein Produktproblem. Es ist ein Kostenproblem. Jede zusätzliche Funktion erhöht Komplexität – und damit die Kosten jeder zukünftigen Änderung.

Und schließlich: Wissen wurde nicht mehr übertragen, sondern ständig neu erfunden. Dokumentation war fragmentiert oder veraltet. Neue Kolleg:innen mussten sich mühsam in implizites Wissen hineinraten. „Relearning“ wurde zum Normalzustand. Das ist nicht nur ineffizient. Das ist ein Risiko. Denn wenn dein System nur durch Köpfe stabil bleibt, ist es nicht stabil.

Wenn du diese drei Dinge kombinierst – langsame Delivery, Feature-Wildwuchs, Relearning – hast du den perfekten Nährboden für den Satz „läuft doch noch“. Nicht, weil es gut läuft. Sondern weil niemand die Rechnung sichtbar macht.

Die Rechnung, die niemand sieht: Kapazität statt Euro

Viele wollen an dieser Stelle sofort Eurozahlen hinschreiben. Das klingt hart, verkauft sich gut, ist aber oft unseriös, weil Teamgröße, Vollkosten und Kontext variieren. Die saubere Währung ist eine andere: Zeitanteile.

Denn Zeitanteile sind die Wahrheit hinter der Fassade. Du kannst über Architektur streiten. Du kannst über Technologie streiten. Aber du kannst nicht wegdiskutieren, was passiert, wenn 80–90% deiner Kapazität im Betrieb versickern.

Und das Spannende in diesem Fall: Der Zustand war nicht gottgegeben. Er war veränderbar. Über mehrere Jahre wurde die Aufteilung sichtbar gedreht:

Ein Jahr später lag die Aufteilung bei 67% Operations & Support und 33% Weiterentwicklung. Danach bei 33% Operations & Support und 67% Weiterentwicklung.

Das ist keine kosmetische Verbesserung. Das ist ein anderes Unternehmen. Zwischen 89% und 33% liegen 56 Prozentpunkte Teamkapazität. Das bedeutet nicht „wir sind ein bisschen effizienter“. Es bedeutet: Aus einem Team, das fast nur noch reagiert, wird wieder eines, das gestalten kann.

Und genau damit ist der Kern dieser Kolumne bewiesen: Der teuerste Teil von „läuft doch noch“ ist nicht der zukünftige Rewrite. Der teuerste Teil ist, dass du heute schon bezahlst – mit einem Team, das nicht mehr liefert.

Warum „läuft doch noch“ so oft durchgeht: weil niemand unterschreibt

Jetzt die unbequeme Wahrheit: Dieser Zustand entsteht selten durch „schlechte Entwickler“. Er entsteht, weil niemand eine klare Entscheidung trifft.

„Läuft doch noch“ ist eine Management-Entscheidung, die sich als technische Einschätzung tarnt. In Wirklichkeit heißt sie: Wir akzeptieren dieses Risiko und diese Kapazitätsverschwendung, weil wir das Budgetgespräch nicht führen wollen. Das ist bequem – bis es nicht mehr bequem ist.

Und das Gefährlichste daran: Sobald ein Team 80–90% seiner Zeit mit Wartung und Reparatur verbringt, beginnt es, diesen Zustand als „normal“ zu behandeln. Dann verschwindet der Kipppunkt aus dem Radar. Der Kipppunkt ist nicht erst der große Ausfall. Der Kipppunkt ist, wenn die Organisation ihre eigene Lieferunfähigkeit nicht mehr als Problem wahrnimmt.

Dann passieren diese absurden Dinge, die jeder aus der Praxis kennt:

• Roadmaps werden geschrieben, obwohl jeder weiß, dass sie nicht lieferbar sind.
• Senior-Leute verbringen ihre Tage mit Kontextwechseln und Incident-Feuerwehr.
• Qualität wird zur Glückssache, weil niemand Zeit hat, sie systematisch abzusichern.
• Frust wird zur Kultur, und Fluktuation zum nächsten Brandbeschleuniger.

Das ist „läuft doch noch“.

Was du daraus ableiten solltest: Ein Check ohne Konsequenz ist Theater

Viele Firmen reagieren auf „läuft doch noch“ mit einem Audit. Das kann sinnvoll sein – oder eine Beruhigungspille. Der Unterschied ist nicht die Qualität des Audits, sondern das Commitment danach.

Wenn du wirklich wissen willst, ob „läuft doch noch“ gerade deine teuerste Aussage ist, brauchst du keine 50 Metriken. Du brauchst genau eine Frage, die dich zwingt, ehrlich zu werden:

“Wie viel Prozent unserer Zeit sind in den letzten vier Wochen echte Weiterentwicklung gewesen?”

Nicht „gefühlt“. Nicht „laut Jira“. Sondern real: Was ist tatsächlich in die Produktion gegangen, was Nutzen bringt – versus Betrieb, Support, Bugfixing, Abstimmung, Warten, Nacharbeiten?

Wenn du da Werte jenseits von 50% Ops/Support siehst, ist „läuft doch noch“ kein Status mehr, sondern ein Alarm. Dann brauchst du innerhalb von 90 Tagen eine echte Entscheidung. Und zwar eine, die jemand unterschreibt:

• gezielt Schuld tilgen, dort, wo es am meisten Luft bringt (Hotspots, Automatisierung, Stabilität),
• schrittweise ablösen, wenn das System strukturell nicht mehr handhabbar ist,
• oder bewusst stilllegen, wenn es keinen Wert mehr liefert und nur noch Komplexität produziert.

Alles andere ist Theater. Und Theater ist im Softwarebetrieb besonders teuer, weil es dich in der Illusion hält, du hättest „etwas getan“, obwohl du nur Zeit gekauft hast.

Unser Future{hacks} Fazit

„Läuft doch noch“ ist teuer, weil es den Moment verschleiert, in dem dein teuerstes Team seine Aufgabe verliert: Wert liefern.

Ein System kann laufen und trotzdem ein schleichender Notfall sein – wenn 89% der Zeit in Operations & Support verschwinden.

Der Punkt ist nicht, dass jedes Legacy-System böse ist. Der Punkt ist: Solange du „läuft“ mit „funktioniert wirtschaftlich“ verwechselst, wirst du systematisch zu spät reagieren.

Die teuerste Phrase ist nicht „Rewrite“. Die teuerste Phrase ist „läuft doch noch“.

Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.