Nachdem wir in Teil 1 der Entwicklerhölle die ersten Schatten durchquert haben mit Tickets, die sich selbst neu schreiben, und Dokumentation, die eher als spirituelle Erfahrung denn als Informationsquelle dient steigen wir nun tiefer hinab.
Denn unter all dem absurden Verhalten wartete manchmal ein Funken Wahrheit: echte Bugs. Mit echter Grundlage. Und einer Umgebung, die alles dafür tat, diese Wahrheit so gut wie möglich zu verschleiern.
Teil 2 – Bugs mit Grundlage
Vom Bauplan bis zum Bug: eine Reise durch absurde Systeme und ihre heiligen Artefakte.
Es gibt zwei Arten von Bugs:
Die, die man findet.
Und die, die einen finden.
Letztere erkennt man daran, dass sie nichts mit Code zu tun haben sondern mit der Umgebung mit:
- Systemzuständen, die nur unter Vollmond und im Beisein dreier Altlasten reproduzierbar sind.
- Dateiformaten, deren Existenz selbst Wikipedia leugnet.
- Init-Ritualen, die eher an Schamanismus erinnern als an Softwarearchitektur.
Willkommen in der nächsten Schicht der Entwicklerhölle:
Dort, wo der Bug nicht das Problem ist – sondern der Weg dorthin.
Bugs mit Grundlage
Sobald ein Ticket einen Bezug hatte – also wirklich ein echter Bug war – wurde es einfach:
Umsetzen. Abgeben. Fertig.
Man lernt schnell:
Nicht alle Bugs sind gleich.
Manche sind halt einfach nur… anders dokumentiert.
Manche Bugs waren trivial. Ein fehlendes isset, ein vergessener Parameter, ein zu spät gerufenes flush() – der eigentliche Fix:
Drei Zeilen. Zwei davon Kommentar.
Aber der Weg dahin?
Ein Abenteuer.
Denn Testumgebungen entsprachen nie der Liveumgebung. Und um die genaue Konstellation nachzustellen, musste man:
- eine alte Datenbankversion einspielen (inkl. 74 custom Migrationsskripten),
- ein diffuses Rechte-System rekonstruieren („Warum hat dieser User eigentlich Zugriff auf diese View?“),
- manuell ein Zip-Archiv entpacken, das in der Doku als „interne Bootstrap-Ressource“ bezeichnet wurde: ohne Hinweis, woher es kam,
- eine externe Software installieren die zwingend notwendig war
- einen Zeitstempel manipulieren, damit das System den Cronjob überhaupt ausführt,
- und ein Phantom-Feature aktivieren, das laut Jira längst gelöscht war.
Und auf dem Desktop musste ein 1×1-Pixel großes Bild liegen. Aber nicht irgendeins.
Die Bild-Datei trug die Endung .pixsql – offiziell ein internes Bildformat, inoffiziell ein systemkritisches Initialisierungsartefakt. Technisch war es ein PNG, praktisch eine binäre Ritualdatei, die nur dann akzeptiert wurde, wenn sie exakt folgenden Kriterien entsprach:
- exakt 1×1 Pixel groß,
- mit GIMP gespeichert (Photoshop veränderte die Byte-Reihenfolge im Alpha-Kanal),
- und mit einer Farbtiefe von exakt 26 Bit.
Letzteres war keine Fehlannahme, sondern Pflicht: Die Prüfung erfolgte zur Laufzeit über eine eigens entwickelte PHP-Extension namens imagebitcheck, die per @dl() eingebunden wurde. Diese analysierte die RGB-Kanäle auf 24 Bit und prüfte zusätzlich, ob zwei weitere Bits im IEND-Chunk einen „Legacy-Kompatibilitätswert“ von 0b11 enthielten. Warum gerade dieser Wert relevant war, wusste niemand. Vermutlich war es ein kosmischer Unfall, den man nie wieder loswurde. Wahrscheinlich wurde er in einer Frühzeit des Systems einmal durch Zufall akzeptiert – und danach nie wieder hinterfragt.
In der letzten Binärzeile des Bildes befand sich ein SQL-Statement – Base64-kodiert, zusätzlich per ROT13 verschlüsselt. Der entschlüsselte Befehl lautete:
SELECT NOW() AS '`cat /dev/urandom`';
Der Sinn dieses Befehls war unklar. Vielleicht prüfte das System, ob es „im Jetzt“ lief. Vielleicht war es einfach ein Test, der sich irgendwann zur Voraussetzung entwickelte. Fakt war: Ohne diesen Aufruf ließ sich das System nicht starten.
Doch das eigentliche Highlight kam, wenn eines der Kriterien fehlte – zum Beispiel die Datei nicht existierte, die Farbtiefe falsch war oder das SQL-Statement nicht lesbar war. In diesem Fall trat ein Fallback-Mechanismus in Kraft, der alles erklärte und zugleich nichts:
[pixsql] boot integrity failed.
invoking fallback: PAP AeroDoc 2.7.3 (post-commit-hook simulation)
Anstelle einer ordentlichen Fehlermeldung generierte das System daraufhin automatisch eine simulierte SVN-Commit-Nachricht. Sie erschien im Logfile als einfache Zeile – scheinbar harmlos, aber völlig sinnfrei:
commit -m "fixed boot by removing time"
Dieser Commit wurde natürlich nicht ausgeführt. Er war Teil eines humorlosen Ironiesystems, das vermutlich aus einem gescheiterten Post-Commit-Hook entstanden war.
Ich weiß nicht mehr, ob das .pixsql-Bild je real war – aber ich weiß, dass ich ähnliche Dinge erlebt habe. Diese Geschichte ist eine Verdichtung von Wahrheit, Wahnsinn und Entwicklerüberleben – Eben eine Entwickler Hölle.
Am Ende war man so erschöpft, dass der Bug selbst zur Erholung wurde.
Der Fix? Schnell gemacht.
Das echte Problem war die Umgebung.
Oder wie ein Kollege mal sagte:
„Wir brauchen keine Tests, wir brauchen einen Schamanen.“
Was das für normale Menschen bedeutet
Stell dir vor, du willst eine defekte Glühbirne in einem Raum austauschen. Die neue Birne liegt bereit das eigentliche Problem ist in drei Sekunden gelöst. Aber bevor du sie einsetzen darfst, musst du:
- den Raum exakt so einrichten wie am Tag der ersten Installation (inklusive der Tapetenwahl und der genauen Position eines Stuhls),
- einen längst verlorenen IKEA-Aufbauplan aus dem Jahr 2004 wiederfinden und Schritt für Schritt durchgehen obwohl es gar kein Möbelstück mehr gibt,
- eine DVD einlegen, die niemand mehr lesen kann, aber die laut Anleitung „spirituell erforderlich“ ist,
- und am Ende eine Lupe nehmen, um auf der Rückseite der alten Birne einen handgeschriebenen Zahlencode zu finden verschlüsselt in Spiegelschrift, mit Zitronensaft.
Wenn du all das gemacht hast, kannst du endlich die neue Birne einsetzen und sie leuchtet sofort. Kein Problem mit der Birne. Nur alles drumherum war eine kafkaeske Prüfung.
Willkommen in der Welt schlecht gewarteter Software.
In Teil 3 am Montag um 13:37 Uhr: Architektur – SOLID aus zweiter Hand
Was passiert, wenn man mit Begriffen wie „Clean Code“, „DI“, „MVC“ oder „SOLID“ um sich wirft, ohne sie wirklich zu verstehen?
Willkommen in einer Welt, in der Architektur mehr nach Theaterkulisse aussieht als nach tragfähigem Fundament und Factories Entscheidungen treffen wie ein Orakel mit Stimmungsschwankung.
Am Montag werfen wir einen Blick in die Design-Illusionen einer Branche, die Prinzipien liebt solange man sie nicht anwenden muss.
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.
