Über diese Serie:
Diese Mini-Serie führt tief hinein in Entwicklerhöllen – dorthin, wo gewachsene Systeme regieren, Prozesse sich verselbstständigen und Logik oft nur ein Vorschlag ist. In mehreren Teilen dokumentiere ich Szenen aus dem Maschinenraum von Enterprise-Software: absurd, komisch, manchmal tragisch aber immer wahr. Wer je in Legacy-Code gewühlt hat, wird sich wiedererkennen.
Oder anders gesagt:
Diese Serie ist auch ein stilles Experiment.
Ein Test, ob Satire nur unterhält
oder ob sie, ganz leise,
im Verlauf der Wochen einen Denkprozess anstößt.
Vielleicht nicht sofort.
Aber irgendwann.
Am fünften Teil.
Oder danach.
Hinweis zur Reihe „Entwicklerhölle“
Diese Reihe ist ein satirisches und literarisch überzeichnetes Langzeit-Protokoll aus 15 Jahren Softwareindustrie von Open-Source über Startups mit Vision bis zu Konzernen mit Governance-Templates aus dem letzten Jahrzehnt und Tochtergesellschaften, die – rein zufällig natürlich – meist genau dort angesiedelt sind, wo Kündigungsschutz eher als historisches Konzept verstanden wird. Von PHP 4 bis PSR-Standards.
Es handelt sich nicht um eine Schilderung meiner aktuellen Tätigkeit, sondern um eine zugespitzte, satirisch überhöhte, aber systemisch ernst gemeinte Aufarbeitung von Erfahrungen, die viele Entwickler:innen so oder so ähnlich gemacht haben.
Wenn du dich wiedererkennst:
Vielleicht, weil du zu gut bist, um sowas zu vergessen.
Und wenn nicht: Umso besser.
Satire trifft Systemdiagnose. Die Hölle ist oft realer als der Quelltext.
Teil 1 – Willkommen in der Entwicklerhölle
Erfahrungsberichte aus den Maschinenräumen der Enterprise-Wartungshölle
Es gibt Projekte, in die kommt man rein und spürt sofort:
„Ich bin zu spät. Hier ist nichts mehr zu retten.“
Manche nennen das Legacy. Andere: Alltag.
Ich nenne es: Entwickler Hölle.
Was folgt, ist eine Sammlung von Erfahrungswerten aus unterschiedlichen Projekten und Unternehmen ein Querschnitt durch die Landschaft der Enterprise-Entwicklung, wie sie sich hinter verschlossenen Türen abspielt.
Die Namen wurden geändert.
Die Schmerzen blieben dieselben.
Ob Startup mit gewachsenen Strukturen, etablierter Mittelstand oder Konzernriese: die Muster wiederholten sich mit erschreckender Konstanz.
Die hier geschilderten Szenen sind nicht die Ausnahme, sondern die Regel.
Sie entstammen keinem einzelnen Albtraum, sondern sind das destillierte Elend einer ganzen Branche, die vergessen hat, dass Software für Menschen gemacht wird von Menschen, die jeden Morgen hoffen, dass heute der Tag ist, an dem endlich alles Sinn ergibt.
Spoiler: Er ist es nicht.
Willkommen in der Zeitmaschine
Meine Abenteuer begannen mit einem einfachen Wunsch: Branches.
Nicht etwa Feature-Branches, wie man sie aus gepflegten Git-Projekten kennt. Nein, hier wurde noch mit SVN gearbeitet.
Ein Apparat, der so historisch ist, dass man es eigentlich nur noch in Museen oder in ISO-zertifizierten Parallelwelten antrifft.
Meine erste Amtshandlung? Eigene Branches anlegen, natürlich lokal, versteht sich.
Merges wollte ich mir angesichts des diffusen Versions-Geflechts nicht auch noch antun.
SVN ist schließlich kein Tool -> es ist ein Zustand.
Dokumentation? Reine Intuition.
Dokumentation gab es keine. Also wirklich: keine.
Was Funktion X tut? Unklar.
Warum sie das tut? Rätselhaft.
Ob sie das soll? Fragt man besser nicht.
Denn dann kommt die Antwort:
„Das ist kein Bug, das ist ein Feature.“
Dass dieses Feature nirgends dokumentiert ist – geschenkt.
Wahrscheinlich wurde es telepathisch überliefert.
Tickets mit Eigenleben
Viele Tickets erledigten sich übrigens ganz von allein.
Man reichte sie an die QA zurück ohne viel Kommentar.
Nicht aus Faulheit, sondern weil man sie schlicht nicht ernst nehmen konnte.
Beispiel gefällig?
Ein Button, der sich in zwei Produkten unterschiedlich verhält.
Große Aufregung: „Bug!“
Nur leider war die Abweichung im Code explizit gewollt.
Das Ticket lebt trotzdem weiter.
Man diskutiert. Und diskutiert. Und diskutiert.
Ich kommentierte:
„Das war eine bewusste Entscheidung, siehe Geschäftsführung.“
Seitdem schwieg ich.
Denn es war alles gesagt.
Nur noch nicht von allen.
Chat-Mitschnitt (fiktiv, dramatisiert, aber nah an der Realität):
PO (leicht atemlos):
„Also Leute, wir müssen über diesen Button reden. In Produkt A macht er dies, in Produkt B macht er das. Wir haben Chaos! Das ist potenziell… markenschädigend!“
QA (panisch blätternd durch Jira-Tickets):
„Wir haben dazu kein offizielles Verhalten dokumentiert! Es gibt keine Akzeptanzkriterien! WIR FLIEGEN BLIND!!“
Entwickler B (fassungslos):
„Das ist ein… Button. Er öffnet entweder ein Dropdown oder ein Modal. Beides funktioniert.“
PO (schreit fast):
„Funktioniert?! WIR SPRECHEN HIER VON INKONSISTENZ! Die UX wird explodieren! Der Kunde merkt sowas! Die klicken da drauf und was, wenn sie das Falsche erwarten?!“
Ich (ruhig, aber innerlich bereits ausgestiegen):
„Es ist exakt so gewollt. Geschäftsführung. Siehe Ticket. Mit Screenshot. Und Anweisung.“
QA (zitternd):
„Ich… ich kann das so nicht freigeben. Ich brauch ein offizielles Go. Vielleicht von ganz oben. Also ganz oben.“
Entwickler B (ironisch):
„Sollen wir das Verhalten einfach würfeln? Jeden Refresh anders? Dann ist’s wenigstens konsequent inkonsequent.“
PO:
„Wir brauchen dringend eine Task-Force. Und ein Cross-Department Alignment. Ich setze ein Doodle auf.“
Ich:
„Oder wir lassen es einfach so. Es ist… ein Button.“
QA:
„Nein. So beginnt das Ende. Erst ein Button. Dann eine Dropdown-Krise. Und am Ende brennt das Release-Board.“. Und dann… dann stehen wir wieder in einem Retro mit ‚Was lief nicht gut‘.“
Ich (murmelnd):
„Wir sind eine Branche mit Buttons. Und keiner weiß mehr, warum.“
Am Donnerstag um 13:37 Uhr in Teil 2: Bugs mit Grundlage
Wenn ein Bug offensichtlich ist, wird’s einfach heißt es. Doch was, wenn das System nur startet, wenn ein 1×1-Pixel-Bild mit 26 Bit Farbtiefe, gespeichert in GIMP und verschlüsselt per ROT13, exakt an der richtigen Stelle liegt? Willkommen bei Fehlern mit Ritualcharakter. Teil 2 widmet sich den tiefen Absurditäten des Debuggings irgendwo zwischen schwarzer Magie und binärer Archäologie.
Rechtlicher Hinweis (Stand: 2025)
Dieser Text ist eine satirisch überzeichnete Verarbeitung beruflicher Erfahrungen aus verschiedenen anonymisierten Projekten. Alle geschilderten Szenen, Dialoge und technischen Konstellationen sind abstrahiert und dienen ausschließlich der Reflexion wiederkehrender Muster in der Softwareentwicklung. Sämtliche technische Beschreibungen sind abstrahiert und stellen keine Rückschlüsse auf konkrete Systemarchitekturen oder Sicherheitsrisiken von Projekten/Unternehmen/Open-Source-Projekten/Aufträgen dar.
Dieser Artikel stellt keine Tatsachenbehauptung über reale Organisationen oder Projekte dar und erhebt keinen Anspruch auf Vollständigkeit oder Objektivität. Die Inhalte sind durch Art. 5 Abs. 1 GG (Meinungs- und Kunstfreiheit) geschützt.
