Nachdem wir in Teil 2 dem Wahnsinn produktionsnaher Debugging-Rituale begegnet sind mit magischen Bilddateien, Base64-verschlüsselten SQL-Kommandos und bugfixenden Schamanen wenden wir uns nun dem zu, was all das überhaupt erst möglich macht: der Architektur.
Oder vielmehr: dem, was in vielen gewachsenen Systemen fälschlich dafür gehalten wird. In Teil 3 geht es um Standards, die keiner versteht, Prinzipien, die nie hinterfragt wurden und um das stille Rückgrat einer Branche, die Chaos durch Obskurität in Struktur verwandelt hat.
Teil 3 – Architektur – SOLID aus zweiter Hand
„Es war kein System. Es sah nur so aus.“
Über den Moment, wenn man erkennt, dass der gesamte Architekturentwurf nur ein zufälliges Nebenprodukt historischer Entscheidungen ist.
Architektur: SOLID aus zweiter Hand
Wenn man schon von Architektur redet:
Interfaces existierten, klar. Man braucht sie ja für Dependency Injection.
Aber benutzt? Selten.
Denn:
„Dependency Injection geht ja nur im Konstruktor. Alles andere ist Quatsch.“
Das Prinzip von schlanken Komponenten, eindeutigen Verantwortlichkeiten und sauberer Trennung?
Galt als akademischer Luxus.
Listener zum Beispiel waren multifunktionale Gott-Klassen.
Man klinkte sich einfach überall ein.
Einige zentrale Listener mischten in jedem Event mit: ganz egal, ob es passte.
MVC? Nur auf dem Papier.
Praktisch war es eher:
EMVCFL – Eventgesteuertes Monolithen-Verhalten mit Verteilten Logiken.
Was das für normale Menschen bedeutet
Stell dir vor, ein Haus soll nach klaren Bauplänen entstehen: Jede Wand hat ihren Platz, jedes Zimmer seine Funktion. Küche ist Küche, Bad ist Bad und die Elektrik ist getrennt vom Wasseranschluss. So sollte Software auch gebaut werden: mit klaren Zuständigkeiten, festen Regeln und Bauteilen, die man austauschen kann.
Aber in diesem Fall?
Das „Haus“ wurde so gebaut, dass in der Küche auch geduscht wurde, im Bad gekocht und die Stromleitungen liefen durchs Klofenster. Es gab schon Baupläne, ja. Aber niemand hat sie gelesen. Oder sie wurden falsch verstanden. Oder einfach nur kopiert, ohne zu verstehen, wofür sie da sind.
Und statt Facharbeiter:innen, die für bestimmte Aufgaben zuständig sind, rannte ein einziger Hausmeister überall gleichzeitig rum löschte Brände, legte Rohre, goss Blumen und schraubte an Sicherungen. Ob er Ahnung davon hatte? Egal. Hauptsache, er war da.
So entsteht keine Ordnung sondern ein Gebäude, das zwar irgendwie steht, aber bei jedem Schritt knarzt, zittert oder dich anschreit, wenn du den Lichtschalter benutzt.
Willkommen in der Architektur zweiter Hand.
Architekturprinzipien? Ja, aber bitte ohne Inhalt
Es gab Architekturprinzipien. Also… Begriffe. SOLID zum Beispiel. Kannte man vom Hörensagen. Aber ob man das „I“ im Interface Segregation Principle für das Intervall oder für das Interface hielt – geschenkt.
Was man benutzte, benutzte man, weil es halt da war. Warum man es benutzte? Fragen wie diese galten als destruktiv.
Reflexion über eingesetzte Konzepte, Frameworks oder Pattern? Gab es nicht. Nicht in leiser Form, Nicht laut, Nicht einmal als Möglichkeit.
ORM, DI, EventBus, Repository: das alles war irgendwie da. Aber niemand stellte die beiden Fragen, auf denen jede ernstzunehmende Architektur eigentlich beruhen sollte:
„Warum machen wir das überhaupt?“ „Und machen wir es richtig?“
Stattdessen herrschte ein kollektiver Modus des:
„Wir haben das schon immer so gemacht.“
Man nutzte Libraries, ohne sie zu verstehen. Man schrieb eigene Services, ohne je über ihren Zweck nachgedacht zu haben. Es wurde auf Abstraktionen gebaut – nicht, um sich zu entkoppeln, sondern um das Gefühl von Architektur zu simulieren.
Es war wie ein Theaterstück mit echten Requisiten, aber ohne Drehbuch.
Dabei war es keineswegs Unsicherheit, die ein Team aus Einzelkämpfern antrieb – im Gegenteil: Die Sicherheit war überwältigend. Man wusste nicht, dass man nichts wusste.
Der Dunning-Kruger-Effekt hatte nicht nur einen festen Platz in der Struktur – er hatte ein eigenes Jira-Board, ein Review-Kontingent und eine Entscheidungsbefugnis.
Selbst triviale Fragen wie „Warum machen wir das hier eigentlich synchron?“ wurden entweder nicht gestellt – oder mit einem Achselzucken beantwortet, das so viel sagte wie:
„Das war halt in der Vorlage.“
Frameworks wurden nicht verstanden, sondern umgangen. Standards wurden nicht geprüft, sondern rekonstruiert. Und wenn irgendwas nicht funktionierte, war nicht der Code schuld, sondern: die Realität.
Was das für normale Menschen bedeutet
Stell dir vor, eine Gruppe baut ein neues Auto aber niemand weiß genau, wie ein Auto funktioniert. Sie haben mal Begriffe gehört wie „ABS“, „Hydraulik“ oder „Sicherheitsgurt“, wissen aber nicht, wofür sie stehen. Trotzdem bauen sie los. Warum? Weil das in irgendeiner Anleitung stand. Vielleicht.
Wenn du fragst: „Warum ist das Lenkrad hinten eingebaut?“ bekommst du nur ein Schulterzucken oder die Antwort: „Das war in der Vorlage so.“
So in etwa fühlte sich die technische Architektur an.
Man benutzte Fachbegriffe wie Dekoration: Sie klangen gut, aber keiner wusste, was sie bedeuteten. Man baute auf Dinge, die eigentlich zum Entlasten da sind und machte damit alles noch komplizierter. Statt sich zu fragen: „Warum machen wir das eigentlich so?“ herrschte eine Kultur des „Nicht-nachfragen-Bitte“.
Es war wie eine Theateraufführung mit teuren Requisiten, aber ohne Drehbuch. Jeder spielte irgendetwas aber niemand wusste, was genau.
Und das Schlimmste?
Die Leute waren sich ihrer Sache sicher. Sie waren überzeugt, alles richtig zu machen. Nicht aus Arroganz sondern weil sie nie gelernt hatten, zu zweifeln.
„Standards bremsen uns doch nur.“
So oder so ähnlich fiel es öfter mit dem Brustton der Überzeugung.
Die allgemeine fachliche Haltung schien zu sein:
Standards seien bestenfalls lästige Korsetts, schlimmstenfalls Innovationshemmer.
Dabei wird gern übersehen, dass echte Innovation nicht im Chaos, sondern auf verlässlicher Basis entsteht.
Wer solide Architekturprinzipien oder Coding-Standards als Einschränkung begreift,
hat den Kern noch nicht verstanden: Freiheit entsteht aus Struktur.
Man kennt das aus dem echten Leben:
In einer aufgeräumten Wohnung findest du Dinge sofort. Du musst nicht überlegen, wo die Schlüssel liegen oder ob im Kühlschrank noch irgendwas Essbares steht. Der Boden ist frei, die Wege sind klar und genau deshalb kannst du dich frei bewegen. Niemand würde auf die Idee kommen zu sagen: „Diese Schubladenstruktur hemmt meine Kreativität.“
Im Gegenteil: Gerade weil alles seinen Platz hat, kannst du spontan sein.
Struktur ist keine Fessel. Sie ist die Voraussetzung für Bewegung.
Und genau so funktioniert auch saubere Architektur:
Nicht als Einschränkung sondern als Fundament, auf dem du überhaupt erst frei entwickeln kannst, ohne Angst, dass alles einstürzt, wenn du die Kaffeemaschine umstellst.
Factories aus der Höllenwerkstatt
Factories waren das Rückgrat des Ganzen.
Doch nicht irgendeine Factory – God-Factories.
Sie wussten alles. Sie entschieden alles.
Und: Sie gaben Dinge zurück abhängig vom Request-Namen (!).
Tracking? Unmöglich.
Vertrauen? Illusion.
Stell dir eine Autofabrik vor.
Du gehst morgens durch das Werkstor, willst wissen, welches Auto heute gebaut wird.
Du fragst den Werksleiter.
Er sagt:
„Kommt drauf an, welchen Namen du auf deinen Zettel geschrieben hast.“
Du: „Okay… Ich hab Sportwagen draufstehen.“
Er: „Ah, dann bauen wir heute einen Traktor.“
Du: „Warum?“
Er: „Weil ‚Sportwagen‘ gestern jemand im System mit Traktor überschrieben hat. Der Kollege aus der Nachtschicht meinte, das passt besser für die Zielgruppe.“
Du willst in die Planung gucken aber die hängt nicht aus. Stattdessen musst du bei einem Pförtner anrufen, der dir den aktuellen Produktionsmodus zuflüstert. Der Modus basiert auf Wetter, Uhrzeit und dem Tagesgericht in der Kantine.
Du fragst nach einem Bauplan bekommst aber stattdessen die Anleitung für einen Toaster.
Begründung:
„War in der Factory so hinterlegt. Wird schon stimmen.“
Ankündigung für Teil 4 – Testing & Reviews in der Entwicklerhölle:
In Teil 4 geht es um das große Missverständnis moderner Softwarequalität: Tests, die alles testen – außer Sinn. Code-Reviews, die mehr über zwischenmenschliche Dynamiken verraten als über Codequalität. Und Entwickler, die den Dunning-Kruger-Effekt so fest in ihren Build-Prozess integriert haben, dass sie ihn für ein Feature halten.
Willkommen in einer Welt, in der @codeCoverageIgnore nicht Ausnahme, sondern System ist.
Teil 4 erscheint kommenden Donnerstag um 13:37 Uhr.
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.
