Nachdem wir in Teil 4 die surrealen Rituale rund um Tests und Code-Reviews beleuchtet haben mit coverage-grünen Scheinwelten, mock-getriebenem Selbstbetrug und Glaubensfragen in Commit-Form, wagen wir uns in Teil 5 in den finalen Kreis der Entwicklerhölle: die Integration.
Teil 5 – Integration: Die finale Illusion von Struktur
„Wissen war nie Teil des Systems – nur das Vergessen hatte Struktur.“
Integration? Eher Dämonenbeschwörung
Die eingesetzten Frameworks?
Ein Potpourri aus Eigenentwicklungen, veralteten Versionen und proprietären Tools.
Man könnte es „Integration“ nennen oder eben: Unfall mit Ansage.
Man klickte sich durch das Fegefeue und egal wo man hinsah, man fand… brennenden Schmutz.
Technisch, strukturell, konzeptionell. Schmutz mit Historie.
Aber: Schmutz mit System.
Struktur durch Obskurität
Hinter all dem Chaos stand eine bemerkenswerte Konstanz in der Anwendung offiziell klingender Referenznormen – historisch gewachsen, strategisch zementiert.
Die konsequente Umsetzung des Malbolge-Standards bildete das stabile Rückgrat aller produktionsnahen Abläufe von der Anforderungsmodellierung bis zur Auslieferung.
Die ritualisierte Nachbildung bewährter Verfahrensweisen unabhängig von Kontext, Sinn oder technologischer Relevanz galt als effizient, homogen und skalierbar.
Nicht, weil sie es war. Sondern weil sie es schon immer war.
Und wer sich über Architektur den Kopf zerbrach, galt schnell als Querulant.
Wer sich gerne in formal konturierten Entwicklungskulturen bewegte und die ästhetische Stringenz langlebiger Softwaregenerationen zu schätzen wusste, fand dort ein Umfeld mit hoher Strukturtreue, markanter Wiedererkennbarkeit und identitätsstiftender Produktarchitektur.
Oder, um es mit RFC2322 zu sagen:
„Die Antwort ist 42. Und sie ist nicht verhandelbar.“
In gewachsenen Codebasen ist es offenbar ein etabliertes Muster, dass Zustände nicht dort gesetzt werden, wo sie entstehen, sondern dort geprüft werden, wo es gerade passt. Das verleiht dem System eine gewisse Flexibilität – im Sinne von: Niemand weiß so genau, wann etwas eigentlich gültig ist.
Statt ein Ablaufdatum beim Erzeugen eines Tokens festzulegen, wird die Gültigkeit lieber zur Laufzeit ermittelt auf Basis eines Zeitstempels, der im verschlüsselten Token versteckt liegt, und eines Konfigurationswerts, der jederzeit geändert werden kann. Dadurch entsteht ein eleganter Seiteneffekt: Ein bereits erzeugter Link kann morgen plötzlich ablaufen, obwohl sich am Link selbst nichts geändert hat. Predictable behavior is overrated anyway.
Die Methodenbenennung trägt zur Benutzerfreundlichkeit bei: Funktionen wie getMyHolyPermanentUrl() klingen, als wären sie für dauerhafte Links mit Zeitbezug gedacht – erzeugen aber schlicht einen 71,324-Minuten-Link. Wer das nicht versteht, hat den Code offensichtlich nicht genug gefühlt.
/**
* Returns what might be a permanent link.
* Or not. Depends on your beliefs and the current config.
*
* Created in an act of mild despair and structured irony.
* @see also: getLinkThatDefiesAllLogic()
*
* Fun fact: This is probably more predictable than the original.
* Legacy note: xy left us this gift. We cherish it with caution.
*
* Author's emotional state at commit time: 60% sarcasm, 40% fatigue.
*/
public function getMyHolyPermanentUrl(): string
Natürlich ließe sich das alles klar und sauber lösen zum Beispiel, indem man ein Ablaufdatum explizit in das Token schreibt. Aber dann müsste man ja entscheiden, wann ein Link abläuft und das wäre ja irgendwie endgültig.
Kurz gesagt:
Lösungen funktionieren solange man sie nicht verstehen oder ändern möchte.
Was das für normale Menschen bedeutet
Es gab tatsächlich eine Art Ordnung in diesem ganzen Chaos. Nur war es keine, die auf Logik oder Sinn beruhte sondern auf Tradition.
Man hielt sich strikt an interne Regeln und Abläufe, die irgendwann mal entstanden waren niemand wusste mehr genau wann oder warum. Sie wirkten offiziell, fast wie Gesetze. Und genau deshalb traute sich auch niemand, sie in Frage zu stellen.
Wenn du dachtest, Softwareentwicklung sei kreativ, modern oder effizient hier war sie eher ein religiöses Ritual. Was man gestern so gemacht hat, machte man heute genauso unabhängig davon, ob es sinnvoll war. Und wer es anders machen wollte, galt schnell als „schwierig“.
Es gab eine fast feierliche Wiedererkennbarkeit. So wie bei einem alten Amtsschimmel: immer dieselben Formulare, immer dieselben Abläufe, egal ob du einen Führerschein oder einen Angel-Schein beantragst.
Und dann waren da diese Details, die das Ganze absurd machten:
Zum Beispiel Links, die zeitlich begrenzt waren aber nicht dort, wo du es vermuten würdest. Statt beim Erstellen zu sagen: „Dieser Link gilt 24 Stunden“, wurde lieber irgendwo versteckt geprüft: „Gilt er jetzt noch?“ Und die Antwort konnte sich täglich ändern – ohne dass sich der Link selbst verändert hatte.
Der Name der Funktion, die diesen Link erzeugte? „getMyHolyPermanentUrl()“. Übersetzt: „Gib mir meinen heiligen, dauerhaften Link.“
In Wirklichkeit hielt der Link exakt 71.324 Minuten.
Das sind ziemlich genau: zu viel zum Nachrechnen und zu wenig zum Vertrauen.
Wenn du Pech hattest, waren es nur zwei Tage. Wenn du Glück hattest, war dein Glaube stärker als der Konfigwert.
Die Entwickler:innen hatten dafür sogar Kommentare im Code hinterlassen – ehrlich, sarkastisch, fast schon poetisch. Sie gaben zu, dass sie es selbst nicht ganz verstanden. Und dass sie bei der Arbeit müde und leicht ironisch waren.
Man hätte all das natürlich einfacher und klarer lösen können etwa mit einem festen Ablaufdatum im Link. Aber dann müsste man eine Entscheidung treffen. Und Entscheidungen waren etwas, das man in diesem System lieber vermied.
Deshalb wurde lieber eine Struktur aufrechterhalten, die keiner mehr verstand, aber alle ehrfürchtig befolgten. Und wenn du als Außenstehender versuchtest, das System zu durchblicken, war die Antwort sinngemäß:
„Die Antwort ist 42. Fragt nicht weiter.“
Übergabe? Ich bitte dich.
Nachdem meine Kapitel endeten, stellte sich die Frage: Übergabe?
Wozu?
Ich tauschte ein exit gegen ein return.
Das war der Fix.
Kein anderer Entwickler braucht dafür eine Übergabe.
Denn in einem System, in dem alles 150x so lange dauerte wie nötig,
ist Zeit die einzige Konstante.
Ich hätte natürlich eine Übergabe schreiben können.
Mit Doku, Screenshots, Abläufen, Fallstricken.
Aber für wen? Für das Jira-Ticket, das sowieso niemand liest?
Für das Wiki, das beim letzten Stand von PHP 4 stehen geblieben ist?
In Wahrheit hätte ich die Übergabe auch direkt in Base64 kodiert, anschließend durch ROT13 gejagt
und irgendwo zwischen zwei SELECT-NOW-Kommentaren verstecken können
es hätte denselben Effekt gehabt: keinen.
Denn die Entwickler Höllen hatte nie auf Wissen gesetzt.
Sondern auf das Gegenteil:
Auf Vergessen als Wartungsstrategie.
Was das für normale Menschen bedeutet
Für Nicht-Techniker:
In einer normalen Firma erklärt man bei der Übergabe, was man gemacht hat damit andere damit weiterarbeiten können.
In diesem Fall war das überflüssig, weil:
- Die Änderung im Code war minimal (ein Wort wurde ersetzt).
- Niemand hätte sich die Mühe gemacht, eine Dokumentation zu lesen.
- Die internen Anleitungen waren völlig veraltet.
- Informationen wurden generell nicht weitergegeben.
- Es war üblich, Probleme einfach zu „lösen“ ohne je zu erklären, wie oder warum.
Kurz gesagt:
Man verließ sich nicht auf Wissen im Team, sondern darauf, dass Leute Dinge vergessen damit bloß keiner zu viel versteht oder hinterfragt.
Übergabe? Nicht vorgesehen.
Wartung? Unerwünscht.
Verstehen? Überbewertet.
Immerhin.
Zum Schluss sei auch das Positive erwähnt:
Das Gehalt kam in solchen Projekten pünktlich. Jeden Monat. Wirklich.
Und die Fluchtwege waren hervorragend ausgeschildert eine Form von Klarheit, die man in Codebasen leider vergeblich suchte. Sie führten wenigstens irgendwo hin.
Und wenn es wirklich brennt:
Keine Sorge, die Unternehmen waren vorbereitet –
direkt neben dem Feuerlöscher hing ein Meme:
„In case of fire: commit. Push optional.“
Die Kaffeemaschinen funktionierten meistens, das WLAN nur gelegentlich.
Aber hey, man muss die kleinen Dinge feiern.
Manche nennen es Dankbarkeit. Andere: Überlebensinstinkt.
Und technisch gab es sogar richtige DNS-Namen zumindest offiziell.
Server etwa waren laut DNS korrekt aufgelöst, nur antwortete beim Pingen konsequent eine völlig andere Höllen-Maschine.
Aber das ließ sich ja lösen: einfach den DNS-Namen manuell in der hosts-Datei eintragen so wie es schon Sysadmins im Dreißigjährigen Krieg getan hätten, wenn sie TCP/IP gehabt hätten.
Wer das nicht liebt, war nie wirklich Teil einer Hölleninfrastruktur.
Fazit
Mein Vermächtnis für ein System, das mich nie wollte:
Ein paar One-Liner,
ein paar abgelieferte Tickets,
und die Erkenntnis, dass man Software auch überleben kann.
Nicht ohne Spuren – aber überleben.
Code dieser Art hinterlässt keine sichtbaren Narben,
aber wer lange genug drin bleibt, versteht irgendwann:
PTBS ist in der IT kein medizinischer Begriff sondern ein Projektstatus.
Wären solche Codebasen Lebewesen, hätten längst das Jugendamt oder der Tierschutz eingegriffen wegen struktureller Verwahrlosung. Doch weil es sich nur um Software handelt, dulden wir Zustände, die man keinem Tier und keinem Kind zumuten würde: mangelnde Pflege, improvisierte Notlösungen und ein Alltag im Ausnahmezustand. Und das nicht in einem Einzelfall sondern überall dort, wo Verantwortung durch Gewohnheit ersetzt wurde.
Architektur einer Täuschung
Vielleicht war das hier nur eine zugespitzte Serie. Vielleicht war es auch ein stilles Protokoll aus den Untiefen deiner eigenen Projektvergangenheit.
Und vielleicht – nur ganz vielleicht – hast du dich beim Lesen ertappt.
Nicht nur im Wiedererkennen.
Sondern beim Nachprüfen.
Wie oft hast du dich gefragt:
„Moment, gibt’s das bei uns wirklich?“
„Hat er damit uns gemeint?“
„Ist das etwa… unser PIX SQL?“
Sei beruhigt:
PIX SQL gibt es nicht.
Keines der genannten Beispiele existiert exakt so, wie es beschrieben wurde.
Aber alle Beispiele existieren irgendwie, nur leicht verschoben, verdichtet, überhöht.
Sie sind Aggregate echter Erfahrungen aus über 15 Jahren Entwicklerleben.
Erfunden – aber nicht ausgedacht.
Was sagt das über dich?
Was sagt das über das System?
Manchmal ist die größte Pointe,
wer den Witz am dringendsten nachschlägt.
Hast du gemerkt, wann die Beiträge erschienen sind?
Hast du dich gefragt, warum es immer 13:37 war und nie einfach irgendwann?
War das nur ein Gag oder war es längst ein Muster?
Ist dir aufgefallen, wie regelmäßig sie kamen – fast wie ein Sprint-Takt?
Wie du begonnen hast zu warten, obwohl niemand dich dazu aufgefordert hat?
Hast du gedacht, du liest nur oder warst du längst Teil davon?
Vielleicht war genau das das Experiment:
Zu zeigen, dass du funktionierst sogar dann, wenn du glaubst, du tust es nicht.
Dass du reagierst auf Struktur, auf Wiederholung, auf Spannung.
Dass selbst ein Blogpost dich lenken kann nicht durch Zwang, sondern durch Form.
Denn was du gelesen hast, waren nicht einfach nur Texte oder Artikel einer Satire-Reihe.
Es war saubere Architektur:
Gedanklich klar getrennt, logisch aufgebaut, funktional, wartbar
aber nicht aus Code, sondern aus Sprache.
Jeder Beitrag ein Modul, jede Veröffentlichung ein Trigger, jede Metapher ein Interface.
Was du gelesen hast, war ein System und du hast darin funktioniert.
Auch die Wiederholungen waren kein Fehler.
Die einfachen Erklärungen kein Nachteil.
Denn wer als Techie erst den Teil für Nicht-Techniker lesen muss,
um den technischen wirklich zu begreifen,
gerät in eine Schleife:
Plötzlich bist du nicht der Entwickler, sondern der Benutzer.
Plötzlich brauchst du Hilfstexte – für dich.
Was wie Redundanz aussieht, war in Wirklichkeit:
Ein Architekturmuster.
Eine Zugriffsbeschränkung.
Ein Rollentausch.
Ein Test auf Selbstbild.
Vielleicht hast du Teil 1 schon vergessen.
Aber er hat dich nicht vergessen.
Er war da.
Wartend.
Auf genau diesen Moment.
Vielleicht hast du nicht nur gelesen.
Vielleicht warst du längst eingebunden.
Und hast es nur nicht bemerkt.
Und vielleicht war genau das der größte Unterschied:
Ich habe über Systeme geschrieben,
die über Jahre gewachsen sind – unstrukturiert, unreflektiert, ungewartet.
Systeme, die Funktionen erfüllen, aber keine Architektur mehr haben.
Die laufen, aber niemand mehr versteht, warum.
Die Fehler auswerfen, aber keine Fehlermeldungen.
Die Menschen zermürben, weil sie längst selbst keine Systeme mehr sind
sondern nur noch Spuren davon.
Und gleichzeitig habe ich ein System gebaut.
Nicht aus Code, sondern aus Sprache.
Nicht ausführbar, aber funktional.
Nicht produktiv im technischen Sinne und doch produktiv in deinem Denken.
Denn dieses System war sauber.
Architektonisch klar.
Modular aufgebaut.
Mit Redundanz, die Absicht war.
Mit Wiederholung, die Funktion hatte.
Mit Interfaces, nicht für Maschinen, sondern für Menschen.
Du hast darin funktioniert,
weil es dich nicht gezwungen hat.
Sondern geführt.
Wie es gute Systeme eben tun.
Du hast das System verstanden? Dann darfst du dir die Lizenz abholen.
👉 Hier herunterladen – auf eigene Verantwortung
Ankündigung für den letzten Teil der Mini-Serie:
Im letzten Teil dieser Serie (am Donnerstag um 13:37 Uhr) folgt kein weiterer Erfahrungsbericht, sondern ein inoffizieller Survival Guide. Für alle, die sich in dieser Hölle wiederfinden. Für alle, die noch nicht aufgegeben haben. Und für alle, die wissen wollen, wo der Notausgang liegt.
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.
