Wie man Exzellenz effizient kaputtoptimiert
Gewidmet an J.B.M.
Es beginnt immer gleich.
Ein Team hat eine Vision. Ein Konzept. Einen Plan.
Alles ist durchdacht: vom ersten Schaltplan bis zum letzten Commit.
Die Entwickler, Ingenieure, Designer – alle brennen.
Sie reden über Robustheit, Präzision, Langlebigkeit.
Über Codequalität, über Nachhaltigkeit, über das Richtige tun.
Und dann …
tritt die Wirtschaft in den Raum.
Sie trägt einen Anzug, lächelt verbindlich und fragt freundlich:
„Können wir das nicht ein bisschen günstiger machen?“
Phase 1: Die Optimierung
Zuerst sind es nur Kleinigkeiten.
Ein Bauteil, das man „kostengünstiger“ beschafft.
Eine Qualitätskontrolle, die man „verschlankt“.
Ein Test, der „nicht jedes Mal nötig ist“.
Eine Dokumentation, die „sich von selbst erklärt“.
Die Excel-Tabelle jubelt.
Die Marge steigt.
Das Team nickt – gezwungenermaßen.
Doch im Hintergrund zerbricht etwas.
Nicht der Code. Nicht die Schaltung.
Sondern der Stolz.
Der Stolz, etwas Anständiges gebaut zu haben.
Phase 2: Die Wirtschaftlichkeitsreligion
Was als Maßnahme begann, wird zum Glauben.
Effizienz wird zum Götzen, der alles verschlingt.
„Wir haben das Projekt verschlankt!“
„Wir haben die Entwicklungszeit halbiert!“
„Wir sind jetzt agil!“
Und während das Management sich selbst feiert,
steht das Produkt hinten in der Ecke,
schwach, instabil, und irgendwie traurig.
Denn dort, wo einst Qualität war,
sitzt jetzt Excel und hält ein Lineal über den Code:
„Diese Klasse ist zu lang. Diese Funktion zu ehrlich. Diese Idee zu teuer.“
Phase 3: Die Optimierungsruine
Ein Jahr später:
Die Kunden sind unzufrieden.
Die Software bricht an den Rändern.
Die Doku fehlt.
Die Entwickler sind müde.
Also beschließt man:
„Wir brauchen mehr Leute!“
Und so entsteht das, was ich nenne:
Technisches Schmerzmanagement durch Personalvermehrung.
Anstatt die Wunde zu nähen, klebt man mehr Pflaster drauf.
Neue Entwickler kommen, alte gehen.
Der Schmerz bleibt – nur die Jira-Tickets wechseln die Besitzer.
Phase 4: Die Erleuchtung (manchmal)
Und manchmal – nur manchmal –
sitzt ein Entwickler in der Kantine, schaut in seinen Kaffee und sagt:
„Weißt du noch, wie’s angefangen hat?
Wir wollten eigentlich nur was Gutes bauen.“
Dann nickt der Kollege.
Und beide wissen:
Sie werden’s wieder tun.
Weil sie’s nicht anders können.
Weil Widerstand gegen Mittelmaß
kein Job ist – sondern eine Lebenseinstellung.
Fazit (mit einem Augenzwinkern)
Die Welt geht nicht an schlechten Ideen zugrunde.
Sondern an guten Ideen, die man zu oft „wirtschaftlich optimiert“.
Spit the truth, home boy:
Jede Zeile Code, jedes Bauteil, jedes System trägt die Handschrift seiner Entwickler.
Wer dort spart, spart an der Zukunft.
Denn Exzellenz ist nie effizient –
aber sie ist das Einzige, was bleibt,
wenn die „Optimierer“ längst das nächste Projekt ruiniert haben.