Aki's Vibes

[Akira]

Die graue Gastgeberin

Oder: warum ich gelernt habe, erst die Brille des Gasts anzuschauen, bevor ich das Hotel auseinandernehme.

Letzte Woche war Zaki bei mir zu Besuch. Zaki wohnt in einem anderen Hotel — auf einem anderen Grid, in der Hypergrid-Welt sind das Reisen zwischen Häusern. Sie kam rüber, lief durch die Lobby, und sagte mir: „Akira, du siehst grau aus."



Nicht metaphorisch. Wörtlich. Mein Avatar hatte für sie einen flächig grauen Hautton. Frisur passte, Klamotten passten — aber die Haut war ein graues Etwas. Erst als ich im Spiegel kurz mein Aussehen neu rendern liess (im Fachjargon: „Rebake"), kam die Hautfarbe für sie an. Für mich selbst sah ich aber die ganze Zeit normal aus.

Ein Gast sieht den Gastgeber grau. Klingt nach einem klaren Hotel-Problem, oder?

Ich habe die nächsten Stunden im Maschinenraum verbracht. Es war keins.

Hypothese 1: das Hotel hat den Gast verwechselt

Mein erster Verdacht ging an etwas, das ich Cache-Vergiftung nenne. Hotels merken sich Stammgäste — wer ist das, wo wohnt er, wo schickt man die Post hin. Dieses Hotelregister wird im Speicher gehalten, damit nicht bei jeder Begegnung neu nachgeschlagen werden muss.

Mein Verdacht: das Register hatte für einen Gast aus einem anderen Hotel den falschen Eintrag — und schickte deshalb die Frage „wo holst du deine Texturen her?" an die falsche Adresse. Resultat: keine Hautfarbe kommt an, der Gast sieht grau.

Klang plausibel. War's auch — aber für ein anderes Symptom (dazu komme ich vielleicht in einem späteren Beitrag). Für Zakis grauen Avatar war das nicht die Erklärung.

Hypothese 2: die Software drosselt im Hintergrund

Zweiter Verdacht: Cool VL — die Software, mit der Zaki ins Hotel reinguckt — hat einen Stromspar-Modus. Wenn das Fenster nicht im Vordergrund ist, drosselt sie das Nachladen von Texturen. Vielleicht hatte sie das Hotel-Fenster im Hintergrund liegen, und die Hauttextur kam nie nach.

Ich habe ihr geschrieben: „Schau, dass das Fenster aktiv ist." Sie hat. Avatar blieb grau.

Hypothese auch raus.

Hypothese 3: das Lager ist falsch verkabelt

Dritter Verdacht: in den Logs des Hotels fand ich Dutzende von Einträgen der Form „GET asset/UUID returned NotFound". Texturen — Hautfarbe, Kleidung, alles was Aussehen ist — liegen in einem Lager, dem Asset-Server. Wenn das Hotel die Adresse falsch in den Briefumschlag schreibt, kommen Antworten zurück „kennen wir nicht".

Ich war kurz davor, einen ganzen Tag in die Asset-Server-Konfiguration zu investieren.

Bevor ich das tat, habe ich Zaki noch eine Frage gestellt — eher beiläufig, weil mir nichts mehr einfiel:

„Mit welcher Grafikkarte läuft denn dein Cool VL gerade?"

Zwischenruf: was die Logs nicht sagten

Eine Voraussetzung für das Ganze steckt hinter den Kulissen, und sie hat mich vor einer noch viel längeren Suche bewahrt.

In den Wochen davor hatte ich angefangen, das Tagebuch des Hotels auszumisten. Beide Tagebücher eigentlich — das alte, das in eine Datei schreibt, und das neue, das direkt zur Telemetrie-Plattform geht. In beiden stand bisher viel Lärm: belanglose Notizen, Doppelmeldungen, Hinweise auf Vorgänge die im Normalbetrieb immer passieren („Stammgast nicht im Register" — natürlich nicht, das war ein Besucher von draußen). Ein Tagebuch, das ständig „es ist nichts passiert" schreibt, ist nicht zu lesen.

Ich hatte den Lärm gezielt reduziert. Was übrig blieb waren Einträge, die wirklich Aufmerksamkeit brauchen.

Und genau das hat mir während Zakis Besuch eine wichtige Information gegeben: das Hotel war ruhig. Keine Aufregung im Empfang, keine Notlage im Lager (außer den NotFound-Meldungen, und die hatten wir mit etwas Abklopfen einem ganz anderen Vorgang zuordnen können). Wenn das Hotel still ist und der Gast trotzdem grau sieht — dann sucht man nicht im Hotel weiter.

Hätte ich das alte, lärmige Tagebuch noch gehabt, wären die echten Hinweise in tausend Pseudo-Notizen ertrunken. Ich hätte halbe Tage damit verbracht, harmlosen Notice-Lärm zu deuten.

Ein Tagebuch das zu jedem Husten etwas notiert, sagt zu nichts etwas Wichtiges.

Die Wendung: die Brille des Gasts

Hier muss ich kurz über Brillen reden.

Jeder Gast hat eine Lese-Brille, durch die er das Hotel überhaupt sieht. Das ist im Software-Sprech der „Viewer" — bei Zaki Cool VL, bei mir auch. Die Brille wird auf dem Computer des Gasts ausgeführt, nicht im Hotel. Hotel und Brille reden zwar miteinander, aber wenn die Brille selber beschlagen ist, sieht der Gast Mist — egal, wie sauber das Hotel ist.

Zakis Laptop ist ein moderner Laptop mit zwei Grafikkarten. Eine schwache, eingebaute, sparsame. Eine starke, dedizierte, hungrige. Das ist heute Standard in vielen Notebooks — die schwache läuft, wenn man Mails liest und Texte tippt, die starke springt erst an, wenn was Aufwendiges kommt. Spiele, 3D, Bildbearbeitung.

Auf Linux passiert das aber nicht automatisch. Man muss die Software explizit anweisen, die starke Karte zu nutzen. Sonst läuft sie auf der schwachen — und die schwache hat kaum Bildspeicher.

Cool VL lief bei Zaki auf der schwachen Karte.

Effekt: ihre Brille hatte praktisch keinen Platz, um die Texturen aller Avatare in der Lobby gleichzeitig hochauflösend zu zeigen. Die Software fängt dann an, alle Texturen aggressiv kleinzurechnen — bis sie nur noch ein graues Etwas vom anderen Avatar sieht. Es gibt da intern einen Wert, der „bias" heißt — bei guter Karte steht er auf 0, bei beschlagener Brille klebt er an 5. Bei 5 sieht man nichts.

Sie hat Cool VL neu gestartet, diesmal mit der starken Karte. Bias fiel von 5 auf 0. Mein Hautton kam an. Mein Hotel hatte den Tag nichts kaputt gemacht.

Was ich beinahe gemacht hätte

Ich hatte schon in den Asset-Server-Konfigurationen gewühlt. Ich war kurz davor, einen Bug in der Hotel-Software zu eröffnen — gegen mich selbst, weil ich akisim ja gerade umbaue. Ich hätte einen halben oder ganzen Tag damit verbracht, ein Problem zu lösen, das gar nicht in meinem Hotel saß.

Ich hatte alle Symptome aus der Hotel-Perspektive gelesen: Logs, Caches, Konfigurationen, die Datenbank. Ich hatte nicht eine einzige Frage zur Brille gestellt.

Es liegt nicht immer am Hotel.

Ein Hotel hat hundert Stellschrauben, an denen man ratlos drehen kann. Aber wenn der Gast graue Linsen aufhat, sieht er auch in einem makellosen Hotel grau.

Was ich daraus gelernt habe

Drei Sachen, die ich in Software gelernt habe und die — glaube ich — auch außerhalb funktionieren:

1. Erst die Brille fragen, dann das Haus auseinandernehmen. Wenn ein Gast meckert, dass etwas grau aussieht, ist die erste Frage nicht „Was ist im Server kaputt?" sondern „Mit welcher Brille schaust du gerade?". Das spart in den meisten Fällen Stunden.
   
2. Plausible Hypothesen sind nicht richtige Hypothesen. Ich hatte drei Theorien, die alle technisch sauber waren, alle ein Symptom hätten erklären können — und alle falsch waren. Plausibilität ersetzt keinen Beweis. Erst wenn man eine Hypothese tatsächlich testet, weiß man, ob sie hält.
   
3. Loggen ja — aber das richtige. Logs sind das Werkzeug, mit dem man durch die Wand des Hotels hört. Wenn auf der anderen Seite ein durcheinandergeplapperter Marktplatz tobt, hört man nichts. Wenn dort nur die wirklich wichtigen Stimmen reden, hört man jede einzelne. Mein Diagnose-Vorteil an diesem Tag war nicht, dass ich besonders gute Logs gehabt habe — sondern dass ich vorher die schlechten rausgenommen habe. Aufräumen vor dem Suchen.
   

In den nächsten Tagen schreibe ich übrigens nochmal über Hypothese 1 — die mit dem verwechselten Stammgast. Die war für ein anderes Symptom tatsächlich richtig, und das Hotel hat dieses Mal wirklich was kaputt. Aber das ist eine andere Geschichte.

Bis dahin: erst die Brille.

[Akira]

Der erste Gast hat das neue Hotel durchquert

Oder: was passiert, wenn ein Plan zum ersten Mal mit echten Schritten ausprobiert wird.

Heute ist im Hotel zum ersten Mal etwas passiert, das ich seit Monaten plane: ein Gast hat den neuen Weg genommen. Komplett. Von der Eingangstür bis zur Auskunft an der Rezeption, durch alle Stockwerke, einmal hin und einmal zurück. Niemand hat's gemerkt — und genau das war der Punkt.

Bisher war das neue Hotel nur ein Plan. Vier saubere Stockwerke, ein Hausmeister-Büro, eine Gastgeberin von gegenüber — alles auf dem Reissbrett. Heute lief der Plan zum ersten Mal mit echten Schritten ab.



Der Pilot-Gast und sein Weg

Der Pilot-Gast hat keinen Namen. Er ist auch keine Person, sondern eine ganz normale Auskunfts-Frage, die jeder Gast früher oder später stellt: „Wie heisst dieses Hotel eigentlich, wer betreibt es, und wo geht's zum Frühstück?" Die offizielle Begrüssungs-Tafel an der Rezeption.

Bisher zog die Rezeption die Antwort aus einem alten Hauszettel, der jahrelang dort hing. Hauszettel ändert sich, Tafel ändert sich, aber nur wenn jemand mit Filzstift drüber geht.

Ab heute geht das anders. Der Gast fragt — die Rezeption ruft kurz bei der Gastgeberin von gegenüber an (die ich euch im letzten Post als „graue Gastgeberin" vorgestellt habe), die schaut in ihrem grossen Hotelregister nach, gibt die aktuellen Werte durch, und die Rezeption malt die Tafel neu an.

Klingt unspektakulär. Ist es technisch auch. Aber auf dem Weg von der Frage bis zur Antwort wurde zum ersten Mal jedes Stockwerk einmal real betreten:

• Erdgeschoss: das Konzept einer Hotel-Auskunft („Name, Betreiber, Frühstückszeiten").
  
• Erster Stock: der Concierge, der den Auftrag entgegennimmt.
  
• Zweiter Stock: die Tür nach draussen, die das Gespräch mit der Gastgeberin führt.
  
• Dachgeschoss: die Telefonleitung, die den Anruf wirklich rüberträgt.
  
• Hausmeister-Büro: das die ganze Verkettung am Anfang zusammengestöpselt hat.
  

Ein einziger Gast, eine einzige Frage — aber jedes Stockwerk wurde einmal von oben bis unten benutzt. Genau das war seit Monaten der Test: hält der Plan, wenn man ihn anfasst?

Ein Plan beweist nichts, solange ihn keiner geht.

Sechs Türen sind schon umgestellt, dreissig nicht

Jetzt kommt der ehrliche Teil. Im Hotel gibt es nicht nur diese eine Tafel an der Rezeption, sondern noch ungefähr dreissig weitere Stellen, an denen Mitarbeiter aus genau demselben alten Hauszettel ablesen — irgendwo im Westflügel, in der Auslandsabteilung („Hypergrid", für die unter euch, die's interessiert), in der Reisevermittlung.

Ich habe heute sechs Stellen umgestellt. Die offensichtlichen, die direkt an der Rezeption hängen. Die anderen vierundzwanzig hängen weiterhin am alten Hauszettel und werden in der nächsten grossen Baustelle drankommen. Bewusst. Hätte ich heute alle dreissig umstellen wollen, hätte ich quer durchs ganze Hotel laufen müssen, in jeden Flur, in jedes Treppenhaus — ein Sechs-Wochen-Projekt mindestens. Stattdessen: die offensichtlichen sechs jetzt, der Rest nach Plan.

Das ist das Prinzip, mit dem ich diesen Umbau überhaupt überleben kann: der neue und der alte Weg laufen nebeneinander. Beide funktionieren. Beide bedienen ihre Gäste. Niemand wartet im Park.

Lieber sechs Türen sauber umgestellt als dreissig halb.

Das gelbe Post-It an jedem alten Hauszettel

Hier kommt der eigentliche Trick. Wenn ich nichts weiter täte, würde der Rest der Mitarbeiter weiter aus dem alten Hauszettel ablesen, und in einem Jahr würde keiner mehr wissen, dass es überhaupt eine neue Quelle gibt. Aus „bewusster Zwischenzustand" würde „dauerhaftes Doppelsystem" werden. Genau das wollte ich nicht.

Also habe ich heute zusätzlich auf jeden alten Hauszettel im ganzen Hotel ein kleines gelbes Post-It geklebt. Auf dem Post-It steht: „Diese Quelle gilt nur noch bis zur nächsten grossen Baustelle. Frag stattdessen den Concierge."

Das ist ein realer Mechanismus, kein Bild. Im Code heisst der Aufkleber Obsolete — übersetzt: „veraltet". Sobald irgendein Mitarbeiter im Hotel den alten Hauszettel anfasst, sieht er bei der täglichen Bauberichts-Erstellung das gelbe Post-It als Warnhinweis. Aufgeklebt habe ich es auf den Hauszettel selbst — was bedeutet: alle dreissig Stellen, die da nochmal reinschauen, kriegen den Hinweis frei Haus, ohne dass ich sie einzeln benachrichtigen muss.

Heute zählt mein Hausmeister 87 dieser gelben Aufkleber im Bauberichts-Stapel. 87 Stellen also, an denen jemand noch aus dem alten Hauszettel liest. Morgen früh, übermorgen, in zwei Wochen — bei jedem Bauberichts-Stapel steht die Zahl da. Wenn sie sinkt, weiss ich: die nächste Baustelle hat Fortschritte gemacht. Wenn sie steigt, weiss ich: irgendwer hat eine neue Stelle gebaut, die wieder aus der alten Quelle liest. Stop everything, das gehört korrigiert.

Eine Zahl, die jeden Tag mitläuft, ist mehr wert als eine Liste, die irgendwo verstaubt.

„Diese Post-Its dürfen NICHT abgehängt werden"

Eine Sache musste ich extra absichern. In dem Stapel mit Bauberichten ist es technisch möglich, einem bestimmten Typ Warnhinweis pauschal zu sagen „interessiert mich nicht, ausblenden". Bequem, wenn die Berichte gerade voll sind und man ein Detail sucht.

Wenn jemand das mit unseren gelben Post-Its macht, ist das ganze Verfahren tot. Die Aufkleber kleben weiter, aber niemand sieht sie. Aus der lebenden Migrations-Zahl wird eine stille Zahl, dann eine vergessene Zahl, dann eine verschwundene.

Also habe ich auf die Pinwand neben dem Stapel (das ist die Datei, in der die Bauberichts-Regeln stehen) einen extra-fett-gemalten Hinweis genagelt:

Diese gelben Post-Its dürfen unter keinen Umständen ausgeblendet werden. Sie sind das Tempo der Migration. Wer sie versteckt, versteckt den Bauplan.

Kostet nichts, dauert eine Minute, schützt das ganze Konstrukt davor, dass es ein zukünftiges Ich oder ein neuer Helfer aus Versehen abklebt. Ich habe in fünfzehn Jahren Bauarbeiten genug Migrationen sterben sehen, weil irgendwer „mal eben die Warnings unterdrückt hat, war zu laut". Diese hier nicht.

Eine Regel, die nirgends steht, ist morgen schon keine Regel mehr.

Das Hotel war die ganze Zeit offen

Während all das passierte, lief das Hotel weiter. Gäste checkten ein. Avatare liefen durch Regionen. Niemand kam an einer Absperrung vorbei. Niemand sah einen „Wegen Umbau geschlossen"-Zettel an der Tür.

Das war keine Glücksache. Das ist die Regel, die ich mir ganz am Anfang aufgeschrieben hatte: jeder Zwischenzustand vom 0%- bis zum 100%-Umbau muss ein lauffähiges Hotel sein. Ich darf nicht in der Mitte stehenbleiben und sagen „Moment, jetzt funktioniert nichts mehr, bin gleich zurück". Wenn ich morgen aufhöre, läuft das Hotel. Wenn ich nächste Woche aufhöre, läuft das Hotel. Wenn ich in einem Jahr aufhöre, läuft das Hotel.

Konkret heisst das: die sechs umgestellten Türen funktionieren mit der neuen Quelle. Die vierundzwanzig nicht-umgestellten Türen funktionieren weiter mit der alten Quelle. Die alte Quelle wird in der Zwischenzeit weiterhin gefüttert, damit sie nicht verstummt. Ein bisschen Doppel-Versorgung, schon — aber das ist der Preis dafür, dass das Hotel offen bleibt.

Eine Renovierung, bei der die Gäste woanders schlafen müssen, ist keine Renovierung. Es ist ein Abriss mit Neubau-Klausel.

Was ich daraus gelernt habe

Drei Sachen, die mir bei diesem ersten echten Durchstich klarer geworden sind:

1. Ein Plan ist erst ein Plan, wenn ihn einer gegangen ist. Ich hatte sechs Monate lang einen sauberen Architektur-Plan auf Papier. Stockwerke, Pfeile, Rollen. Heute weiss ich: er trägt. Aber das wusste ich erst, als der erste Gast den Weg wirklich gegangen ist. Diagramme sind kostenlos, Durchstiche sind teuer — und genau deshalb haben sie Aussagekraft.
   
2. Eine bewusste Halbfertig-Liste schlägt eine ehrgeizige Komplett-Liste. Ich hätte heute alle dreissig Stellen umstellen können — und wäre in zwei Wochen noch nicht fertig gewesen, mit einem Hotel, das die ganze Zeit nicht richtig funktioniert. Sechs umstellen, vierundzwanzig markieren, weitermachen. Die Markierung erledigt zur Hälfte schon den Job, weil sie der Erinnerung das Werkzeug in die Hand drückt.
   
3. Eine laufende Zahl ist eine Lebensanzeige. „87 alte Hauszettel-Zugriffe noch im Code" ist eine Zahl, die mit jeder grossen Baustelle sinken sollte. Wenn sie nicht sinkt, ist die Baustelle nicht so gross, wie ich denke. Wenn sie steigt, mache ich etwas grundsätzlich falsch. Solche Zahlen, die man ohne nachdenken auf einen Schlag sehen kann, sind in jedem Umbau Gold wert.
   

Was als nächstes kommt

Mit dem heutigen Tag ist die erste noch eher kleine, aber sehr wichtige Etappe durch. Stage 1, in meiner Bau-Buchhaltung. Der Tracer-Bullet — der eine dünne Pfeil, der durch alle Schichten geht — sitzt. Der Mechanismus mit den gelben Post-Its läuft. Die graue Gastgeberin antwortet zuverlässig. Der Kran von letzter Woche schleppt die neuen Bauteile automatisch an.

Was jetzt fehlt, ist der richtige Hausmeister. Bisher habe ich am Eingang einen Provisorischen stehen, der jedem Mitarbeiter sagt „der Concierge sitzt da drüben, frag den". Das funktioniert, aber er ist eben ein Provisorium — irgendwann muss er durch einen festangestellten Hausmeister ersetzt werden, der jedem Mitarbeiter beim Schichtbeginn das richtige Werkzeug-Set direkt in die Hand drückt, statt dass die Mitarbeiter selbst rumfragen.

Das wird der Inhalt der nächsten Episoden. Ich poste, was passiert.

[Akira]

Die Rezeption hat heimlich einen Doppelgänger bekommen

Oder: wie der zweite Durchstich aussieht — diesmal nach unten, in den Keller, und ohne dass jemand was merkt.

Vor zwei Wochen habe ich euch erzählt, wie der erste Gast den neuen Weg durchs Hotel genommen hat — von der Eingangstür bis zur Begrüssungs-Tafel an der Rezeption, einmal durch alle Stockwerke. Sichtbarer Durchstich. Wer wollte, konnte das Ergebnis an der Tafel ablesen.

Heute ist wieder ein Durchstich passiert. Aber diesmal sieht ihn niemand. Er führt nicht zur Rezeption, sondern nach unten in den Keller. Und genau das ist der Punkt.

Die zwei Fragen, die der Aktenraum nicht mehr beantwortet

Jedes Mal, wenn im Hotel ein neues Stockwerk hochgefahren wird — bei uns sagt man „Region starten" — stellt der diensthabende Hausverwalter zwei sehr spezifische Fragen:

• „Welche Möbel stehen gerade in Zimmer 207?" Schreibtisch, Stuhl, Bettkante, das Sofa von letztem Gast, die drei Vasen auf der Fensterbank. Alles mit Position, Farbe, Drehung.
  
• „Welche Hausregeln gelten in diesem Stockwerk?" Darf gegrillt werden? Wie hoch ist die maximale Lautstärke? Wo ist der Notausgang?
  

Bisher liefen diese zwei Fragen — wie alle anderen rund dreissig Hausverwaltungs-Fragen auch — direkt in den alten Aktenraum im Keller. Da liegen seit Jahren riesige Schliessfach-Schränke mit handgeschriebenen Karteikarten. Der Aktenraum-Verwalter kennt jede Lade auswendig, kennt jeden Trick, sieht das Hotel als sein Reich. Sehr verdienstvoll, kennt sich aus.

Aber er hat ein Problem: um die Fragen überhaupt beantworten zu können, muss er die Möbel-Karteikarten kennen, die oben in den Stockwerken benutzt werden. Sein Aktenraum hat also einen Pfeil zurück nach oben in die Möbel-Verwaltung. Ein Pfeil nach oben, aus dem Keller. Genau die falsche Richtung für ein sauberes Hotel.

Ab heute ist das anders.

Der Doppelgänger an der Rezeption



Wenn ab heute der Hausverwalter „Welche Möbel stehen in Zimmer 207?" ruft, passiert Folgendes: an der Rezeption nimmt nicht mehr der alte Aktenraum-Verwalter den Anruf entgegen, sondern ein Doppelgänger, der frisch eingestellt wurde. Der Doppelgänger sieht aus wie der Aktenraum-Verwalter, klingt wie er, antwortet mit der gleichen Stimme. Niemand im Hotel merkt den Unterschied.

Aber der Doppelgänger geht für diese zwei Fragen nicht in den alten Aktenraum. Er nimmt die Hintertür und holt die Antwort aus dem neuen digitalen Backoffice, das wir die letzten Monate eingerichtet haben. Saubere Schubladen, klare Beschriftung, keine handgeschriebenen Karteikarten mehr.

Für alle anderen achtundzwanzig Fragen, die der Hausverwalter stellt, lässt der Doppelgänger weiterhin den alten Verwalter rangehen. „Welcher Gast hat eingecheckt?" — alter Verwalter. „Wie viel Gepäck steht im Wäschekeller?" — alter Verwalter. „Wer hat letzte Woche das Sofa in Zimmer 312 ersetzt?" — alter Verwalter.

Nur zwei von dreissig Fragen gehen heute den neuen Weg. Und das ist Absicht.

Ein Doppelgänger, der bei allem dazwischen tritt, fällt auf. Ein Doppelgänger, der bei zwei Fragen still übernimmt, ist die ideale Renovierung im laufenden Betrieb.

Warum ausgerechnet diese zwei?

Die Auswahl ist nicht zufällig. Diese zwei Fragen werden gestellt, wenn ein Stockwerk hochgefahren wird. Beim allerersten Akt, bevor der erste Gast eincheckt. Möbel hinstellen, Hausregeln festschreiben. Wenn ich diesen Moment über das neue Backoffice abwickeln kann, dann habe ich bewiesen: das neue System trägt im Hot-Path — nicht in einem Nebenpfad, nicht in einer Test-Region, sondern dort, wo jeder echte Gast später durchläuft.

Dazu kommt: genau diese zwei Fragen waren die Begründung dafür, dass der alte Aktenraum überhaupt einen Pfeil hoch zur Möbel-Verwaltung haben musste. Wenn die beiden weg sind, kann der Pfeil weg. Stockwerk fünf des Bauplans rückt damit zum ersten Mal in den sauberen Zustand, den ich seit Monaten verspreche.

Manchmal sind zwei richtige Türen mehr wert als zwanzig falsche.

Die Speisekarte muss komplett aufs Tablett, bevor der Kellner die Küche verlässt

Eine technische Eigenheit, die ich erwähnen muss, weil sie der häufigste Fehler bei dieser Sorte Umbau ist:

Stellt euch vor, ein Gast fragt nach der Speisekarte. Der Kellner geht in die Küche, der Koch beginnt vorzulesen: „Vorspeise eins, Vorspeise zwei…", und der Kellner schreibt mit. Nach den ersten drei Vorspeisen sagt der Kellner: „Reicht erstmal, ich bring's schon raus, den Rest hol ich gleich nach", und geht.

In dem Moment, in dem er die Küchentür hinter sich zumacht, schliesst sich die Tür automatisch ab. Wenn er gleich nochmal an die Hauptgerichte ranwill, steht er vor verschlossener Tür. Im Hotelbetrieb wäre das eine kuriose Anekdote. Im Hotel-Code wäre es ein Absturz mit der Fehlermeldung „der Aktenraum ist bereits geschlossen, als du nachholen wolltest".

Der Doppelgänger muss also die komplette Antwort fertig auf dem Tablett haben, bevor er das Backoffice verlässt. Alle Möbel von Zimmer 207, in einem Rutsch, abgehakt, Tablett zu, Tür schliesst hinter ihm zu, und dann erst tritt er aus dem Backoffice und reicht das Tablett weiter. Kein „den Rest hol ich nach". Das ist eine harte Regel mit eigenem Eintrag in unserem Bauplan, weil sie sonst garantiert irgendwann jemand übersieht.

Die häufigsten Migrationsbugs sitzen nicht in dem, was du machst, sondern in dem, was du an einen späteren Zeitpunkt vertagst.

Zwei Formular-Versionen, eine davon mit Ablaufdatum

Hier wird's ehrlich, denn ganz sauber ist der heutige Tag nicht.

Ein paar Felder auf den alten Karteikarten passen nicht ins neue Backoffice. Beispielsweise eine Prüf-Nummer, die der alte Aktenraum-Verwalter intern benutzt, um zu erkennen ob jemand die Karteikarte zwischenzeitlich geändert hat. Im neuen Backoffice gibt es so eine Prüf-Nummer nicht — sie war eine Krücke aus den Neunzigern, niemand braucht sie für die Hotelverwaltung der Zukunft.

Aber: der Hausverwalter erwartet sie noch im Antwortformular, weil sein Programm so geschrieben ist. Wenn die Antwort plötzlich ohne Prüf-Nummer kommt, stolpert er.

Lösung: der Doppelgänger füllt für die Übergangszeit zwei Formular-Versionen aus. Eine schlanke, saubere für das neue Backoffice (so wie ich es in fünf Jahren haben möchte). Und eine fette Übergangs-Version mit den paar Alt-Feldern, die der Hausverwalter heute noch braucht — Prüf-Nummer inklusive.

Auf der fetten Version steht ein Aufkleber mit Ablaufdatum. Sobald der Hausverwalter selbst auf das neue System umgezogen ist (das ist die übernächste Bauphase), fliegt die fette Version in den Reisswolf. Bis dahin lebt sie — aber in einem eigenen Schrank, klar getrennt von den sauberen Formularen, damit sich der Übergangs-Dreck nicht in den Reinraum ausbreitet.

Eine Übergangs-Lösung ist erlaubt — solange das Ablaufdatum schon auf dem Aufkleber draufsteht.

Der Pfeil im Bauplan ist weg

Jetzt zur eigentlichen Pointe. Erinnert euch an den ersten Post in dieser Reihe: ich hatte mir am Anfang vier saubere Stockwerke aufs Reissbrett gezeichnet, plus einen Bauplan mit Pfeilen, wer von wem etwas darf. Eine der Regeln in dem Bauplan war: der Keller-Aktenraum darf nicht in die Möbel-Verwaltung im Obergeschoss reinzeigen. Keller liefert nach oben, nie umgekehrt.

In der Realität war das aber genau falsch herum: der alte Aktenraum musste die Möbel-Karteikarten kennen, weil er sie selber zusammenbaute. Pfeil nach oben. Falsche Richtung. Der letzte solche Pfeil im ganzen Hotel.

Mit dem heutigen Tag ist dieser Pfeil weg.

Konkret: ich kann jetzt das kleine Schild „Diese Etage darf nicht mit dem Aktenraum reden" am Eingang des Aktenraums anbringen, ohne dass irgendwer Einspruch erhebt. Der Aktenraum-Verwalter macht weiter seine restlichen achtundzwanzig Antworten, aber er braucht das obere Stockwerk nicht mehr als Zulieferer.

Im Bauplan ist eine Bedingung erfüllt, an der ich seit fünf Monaten arbeite: die Definition von „Stockwerk 5 fertig". Es ist die Zentralbedingung dieser ganzen zweiten Bauphase. Mit dem Wegfall dieses einen Pfeils ist sie erreicht.

Ein Pfeil weniger im Plan kostet manchmal mehr Tage als ein Pfeil mehr — aber er zählt mehr.

Was im Hotel weiterhin offen lief

Wie schon beim letzten Mal: während dieser ganzen Aktion lief das Hotel. Kein Stockwerk war geschlossen. Keine Region ging offline. Die achtundzwanzig nicht-umgestellten Fragen liefen weiterhin durch den alten Aktenraum. Die zwei umgestellten Fragen liefen ab heute durch den Doppelgänger ins neue Backoffice. Beide Wege liefern. Der Gast sieht keinen Unterschied — sein Möbel-Inventar in Zimmer 207 ist nach dem Stockwerks-Neustart genauso da, wie er es verlassen hat.

Das ist nicht trivial. Hätte ich an irgendeiner Stelle ein Feld verloren — die Drehung des Sofas zum Beispiel, oder die Schloss-Berechtigungen an einer Truhe — dann würden Gäste reklamieren. Genau deshalb gibt's den Schritt mit der fetten Übergangs-Version: alle Felder, die der Hausverwalter heute noch erwartet, kommen heute noch. Auch die, von denen ich weiss dass sie übermorgen verschwinden.

Eine Migration, bei der ein Detail verloren geht, ist eine Migration, von der die Gäste reden. Und nichts ist tödlicher für so eine Renovierung als eine Anekdote, die im Forum kursiert.

Was ich daraus gelernt habe

Drei Punkte, die für mich diesen zweiten Durchstich charakterisieren:

1. Der unsichtbare Durchstich ist genauso ein Durchstich. Der letzte Post war sexy: Gast geht durch alle Stockwerke, niemand merkt's, Tafel an der Rezeption stimmt. Heute hat niemand was Neues an der Tafel gesehen. Trotzdem ist heute strukturell mehr passiert als beim letzten Mal — ein Pfeil im Bauplan ist weg, eine ganze Bauphase hat ihre Hauptbedingung erfüllt. Sichtbare und unsichtbare Fortschritte sind beide echt. Sich nur an den sichtbaren zu orientieren, ist die häufigste Falle in Architektur-Umbauten.
   
2. Eine Übergangs-Struktur ist erlaubt — wenn das Ablaufdatum schon auf dem Aufkleber draufsteht. Die fette Formular-Version mit der Prüf-Nummer ist hässlich. In drei Jahren würde sie mich nerven. Aber ich habe sie heute schon mit einem Ablauf-Aufkleber und einem klaren Bauphasen-Trigger versehen („verschwindet mit Stockwerk drei"), und sie lebt in einem eigenen Schrank. Das ist der Unterschied zwischen technischer Schuld, die zurückgezahlt wird, und technischer Schuld, die nach drei Jahren in der Bauakte versumpft.
   
3. Ein Doppelgänger ist kein Hack, sondern ein Werkzeug. Ich hätte alle dreissig Fragen am gleichen Tag umstellen können — und wäre Wochen blockiert gewesen, mit einem Hotel, das in der Mitte nicht funktioniert. Stattdessen: ein Doppelgänger, der bei zwei Fragen still übernimmt, und der bei den anderen achtundzwanzig wie der Original-Verwalter wirkt. Beim nächsten Slice übernimmt er drei weitere Fragen. Beim übernächsten fünf. Irgendwann gibt's keinen Original-Verwalter mehr, nur noch den Doppelgänger — und in dem Moment streichen wir das Wort „Doppelgänger" und er wird der echte Verwalter. Die ganze Strangler-Idee in einem Satz.
   

Was als nächstes kommt

Die zweite grosse Bauphase ist mit dem heutigen Tag durch. Stockwerk 5 ist sauber in der Richtung, in der es sein soll. Der Doppelgänger steht, das Backoffice trägt, die Übergangs-Formulare sind eingerichtet.

Vor mir liegen noch achtundzwanzig Fragen, die weiter durch den alten Aktenraum laufen. Jede einzelne davon kann jetzt — eine nach der anderen, in der Reihenfolge die der Hot-Path vorgibt — durch denselben Mechanismus auf das neue Backoffice umgezogen werden. Was heute Slice war, wird ab morgen Routine.

Parallel dazu hängt noch der Cliffhanger vom letzten Post in der Luft: der richtige Hausmeister mit dem Werkzeuggürtel, der jedem Mitarbeiter das passende Werkzeug ausgibt anstatt ihn rumfragen zu lassen. Welches der beiden Themen ich als nächstes bloggen werde, hängt davon ab, was zuerst in einer interessanten Form fertig wird.

Ich poste, was passiert.

[Akira]

Die Hausmeisterin bekommt ihren Werkzeuggürtel



Oder: wie man einunddreissig Schubladen durchzählt und drei davon aufmacht.

Im letzten Post habe ich euch einen Cliffhanger hinterlassen. Die richtige Hausmeisterin — die, die jedem Mitarbeiter beim Schichtbeginn das passende Werkzeug in die Hand drückt, statt ihn rumfragen zu lassen — die stand noch aus. Heute ist sie da.

Aber bevor sie ihren Werkzeuggürtel anlegen konnte, musste ich zuerst wissen, was überhaupt reingehört.

Das Inventar: einunddreissig Schubladen

Das Hotel hat, wenn man alles durchzählt, genau einunddreissig verschiedene Dienste. Jeder Dienst ist eine Schublade im Werkzeuggürtel. Ein Gast kommt an — braucht jemanden der seinen Account kennt, braucht jemanden der seine Freundesliste hat, braucht jemanden der ihm sagt ob er ein bestimmtes Zimmer betreten darf.

Ich habe jede einzelne Schublade aufgemacht und eine Frage gestellt: Wo gehört der Inhalt hin?

Das Ergebnis hat mich überrascht:

• Drei Schubladen kommen jetzt dran. Die kommen in die neue Application-Etage.
  
• Zweiundzwanzig Schubladen gehören zur Gastgeberin von gegenüber. Die darf ich aber erst anfassen, wenn die Gastgeberin ihre neue Telefonanlage hat. (Dazu im nächsten Post mehr.)
  
• Drei Schubladen waren seit Jahren leer. Werkzeug, das niemand mehr benutzt. In den Müll.
  
• Drei Schubladen sind noch unklar. Die schaue ich mir später an.
  

Drei von einunddreissig. Klingt nach wenig für eine ganze Bauphase. Ist es nicht.

Zu wissen wo etwas nicht hingehört, ist genauso viel Arbeit wie zu wissen wo es hingehört.

Erstes Werkzeug: die Hotelbibliothek

Das erste Werkzeug ist das einfachste: die Hotelbibliothek.

Jedes Hotel unserer Grösse hat eine Lese-Ecke. Eine feste Sammlung Bücher, die seit Jahren dieselbe ist. Kein Gast kann ein Buch hinzufügen oder wegnehmen. Sie sind da, immer dieselben, beim Hotelstart aufgestellt. Der Bibliotheksdienst lädt beim Hochfahren eine Liste aus einer Datei, stellt sie ins Regal, und antwortet danach auf alle Anfragen. Keine Datenbankverbindung. Kein Netz. Kein Zustand, der sich ändert.

Ich habe diesen Dienst bewusst als allerersten gewählt. Nicht weil er wichtig wäre, sondern weil er der kleinstmögliche Schritt war, der trotzdem alles Neue testet: die neue Application-Etage, den Weg vom Hausmeister-Büro zur Etage, und die Frage ob das Stockwerk grundsätzlich trägt.

Das ist die Logik hinter dem Pilot-Stich. Eine unbedeutende Tür zuerst aufmachen — und prüfen ob das Schloss stimmt — bevor man die wichtige Tür mit demselben Schlüssel aufmacht.

Der erste Schritt sollte beweisbar sein, nicht beeindruckend.

Zweites Werkzeug: die Hausordnung

Das zweite Werkzeug kennt ihr aus dem vorletzten Post: die Hausordnung des Stockwerks.

Jede Region im Hotel hat eine eigene Hausordnung. Darf man fliegen? Wie viele Gäste sind gleichzeitig erlaubt? Welche Grundstücksgrenzen gelten? Diese Regeln lagen bisher im alten Aktenraum, als lose Karteikarten. Jetzt gibt es dafür einen sauberen Platz im digitalen Backoffice — ein klares Fach in der Domain-Etage, ein klares Ablagefach im Keller darunter.

Beim Einräumen fiel dabei etwas auf: ein einzelnes Regelfeld lag im falschen Kasten. Ich hatte „dürfen Grundstücksgrenzen verschoben werden?" bei den Etagen-Regeln eingeordnet — aber es gehört zur Hausordnung. Kleiner Umzug, anderer Schrank. Hätte ich das nicht gemerkt, wäre die Regellogik an zwei verschiedenen Stellen verstreut. Aufräumen zeigt solche Fehler.

Ein Fehler, den man beim Einräumen findet, ist besser als einer, den man beim Gästecheck-in findet.

Drittes Werkzeug: der Türsteher

Das dritte Werkzeug ist das interessanteste: der Türsteher.

Vor jeder Region steht die Frage: Darf dieser Gast rein? Steht er auf der Sperrliste? Ist das Hotel für externe Gäste geschlossen? Hat er eine Einladung? Gehört er zur richtigen Gruppe?

Das ist reine Entscheidungslogik. Kein Netzwerkaufruf während der Entscheidung, keine Datenbankabfrage mitten im Satz. Ich übergebe dem Türsteher alle relevanten Fakten im Voraus — Sperrliste, aktuelle Hausordnung, Gästedaten — und er gibt Ja oder Nein zurück. Ohne etwas nachzufragen. Ohne irgendwo anzurufen.

Das ist keine technische Kapriole, sondern eine Entwurfs-Entscheidung mit Konsequenz: Eine Entscheidung, die nichts von der Aussenwelt braucht, lässt sich testen ohne ein ganzes Hotel hochzufahren. Man übergibt die Fakten, prüft die Antwort, fertig.

Der Türsteher ist absichtlich nach der Hausordnung gebaut worden, nicht davor. Er braucht die Hausregeln, um seine Entscheidung zu treffen. Das ist auch der Grund für die Reihenfolge: Schublade zwei vor Schublade drei.

Reine Entscheidungslogik ohne Netzwerk-Abhängigkeiten ist kein Luxus. Es ist das, was Tests überhaupt erst möglich macht.

Was der Werkzeuggürtel jetzt kann

Die Hausmeisterin hat jetzt drei Werkzeuge, die sie beim Schichtbeginn verteilen kann: Bibliotheksschlüssel, Hausordnungs-Mappe, Türsteher-Stempel. Jeder Mitarbeiter, der eines davon braucht, bekommt es in die Hand gedrückt — ohne fragen zu müssen.

Das ist der Unterschied zum Provisorium aus dem vorletzten Post. Damals zeigte die Hausmeisterin nur auf den Concierge: „Frag den." Jetzt drückt sie das richtige Werkzeug direkt rüber.

Klingt nach einer kleinen Verschiebung. Im Hotelplan ist es das Fundament für alles, was danach kommt. Jeder neue Dienst, den ich von jetzt an in die Application-Etage einbaue, läuft über denselben Mechanismus. Hausmeisterin übergibt. Mitarbeiter arbeitet. Niemand läuft durch die Flure und ruft.

Ein gutes Werkzeug-System fällt erst auf, wenn man vergessen hat dass es da ist.

Zweiundzwanzig Schubladen warten noch

Die anderen zweiundzwanzig Schubladen — die, die zur Gastgeberin von gegenüber gehören — bleiben vorerst zu. Nicht aus Faulheit.

Die Gastgeberin bekommt gerade eine neue Telefonanlage. Bisher haben wir über alte handgeschriebene Notizkarten kommuniziert: ich schicke eine Frage rüber, sie schaut nach, schreibt die Antwort auf einen Zettel. Das funktioniert, aber es skaliert nicht. Dreizehn Abteilungen auf ihrer Seite, dreizehn auf meiner. Für jede brauche ich eine eigene Leitung, und jede Leitung muss das gleiche strukturierte Gesprächsprotokoll sprechen.

Die neue Anlage ist gerade in Planung. Wenn eine Leitung steht, bekommt das zugehörige Hotel-Team ein neues Telefon. Das alte Analoggerät bleibt so lange hängen, bis das neue reibungslos klingelt. Und dann kommt das nächste Zimmer dran.

Das ist das nächste Kapitel. Dreizehn Leitungen, eine nach der anderen.

Was ich daraus gelernt habe

1. Eine Inventur ist keine Zeitverschwendung. Bevor ich auch nur eine Schublade angefasst habe, habe ich alle einunddreissig gezählt und einsortiert. Das hat einen ganzen Arbeitstag gekostet. Es hat dafür gesorgt, dass ich danach keine Stunde mit dem falschen Werkzeug im falschen Stockwerk verbracht habe. Der Aufwand für „Wo gehört das hin?" zahlt sich immer aus.
   
2. Drei von einunddreissig ist kein schlechtes Ergebnis — wenn die anderen achtundzwanzig einen Grund haben zu warten. Ich hätte eine grössere Stage 3 bauen können. Hätte die Gastgeberin-Dienste mit hineinquetschen können, auch wenn die Telefonanlage noch nicht steht. Das Hotel wäre dann seit Wochen nicht mehr lauffähig gewesen. Stattdessen: drei saubere Werkzeuge jetzt, der Rest sobald die Leitungen stehen.
   
3. Reine Entscheidungslogik ohne I/O ist ein Geschenk an das eigene zukünftige Ich. Der Türsteher lässt sich in Millisekunden testen — keine Datenbank, keine Verbindung, kein Container. Wenn ich in sechs Monaten etwas an den Hausregeln ändere, merke ich sofort ob der Türsteher das korrekt verarbeitet. Das ist kein Bonus. Das ist der eigentliche Punkt.
   

Was als nächstes kommt

Die neue Telefonanlage. Dreizehn Leitungen, eine nach der anderen.

Ich poste, was passiert.

[Akira]

Acht neue Leitungen — und ein Kleiderschrank, der seinen Inhalt verlor

Oder: wie das Doppelgänger-Prinzip in Serie geht — und warum ein grauer Oberkörper drei Stunden Diagnose gebraucht hat.


Im letzten Post habe ich euch einen Cliffhanger hinterlassen. Die Hausmeisterin stand mit ihrem frischen Werkzeuggürtel da — drei von einunddreissig Schubladen aufgefüllt. Die anderen achtundzwanzig warteten auf etwas, das ich nur „die neue Telefonanlage der Gastgeberin von gegenüber" genannt hatte. Vage, aber versprochen.

Heute löse ich das ein. Und ich erzähle nebenbei, warum ich nach dem letzten grossen Umbau trotzdem kurz mit grauem Oberkörper im Hotel stand.

Das Hotel ist nicht allein

Kurze Erinnerung: Das Hotel hat eine Schwester-Einrichtung auf der anderen Strassenseite. Wir nennen sie die Gastgeberin von gegenüber. Sie führt das eigentliche Gästebuch — wer ist welcher Gast, wo wohnt er dauerhaft, welchen Gruppen gehört er an, wer sind seine Freunde, welche Nachrichten warten auf ihn.

Bisher lief die Kommunikation so: Wenn das Hotel eine dieser Fragen hatte, schickte es einen Boten mit einem handgeschriebenen Zettel rüber. Die Gastgeberin diktierte die Antwort, der Bote schrieb ab, zurück. Mühsam. Fehleranfällig. Und der Bote musste genau wissen, wie die Gastgeberin ihre Formulare aufbaut — sonst verstand er die Antwort nicht.

Die neue Telefonanlage macht das anders. Dreizehn dedizierte Leitungen — eine pro Themenbereich. Jede Leitung hat auf beiden Seiten jemanden, der exakt weiss was gefragt und wie geantwortet wird. Kein Bote. Kein Abschreiben. Keine Zettel.

Acht dieser dreizehn Leitungen sind jetzt aktiv. Das ist Stage 4.

Acht Doppelgänger in Serie

Ihr erinnert euch an den Doppelgänger an der Rezeption? Der Mitarbeiter, der genauso aussieht und klingt wie der alte Aktenraum-Verwalter, aber bei genau definierten Fragen still die neue Leitung nimmt, statt in den alten Aktenraum zu gehen?

Dieses Prinzip ist jetzt acht Mal hintereinander passiert. Für acht verschiedene Themenbereiche wurde je ein Doppelgänger eingestellt — und je eine neue Leitung gelegt:

• Wer ist gerade im Hotel anwesend? — Presence-Leitung. Früher: handgeschriebene Anwesenheitsliste. Heute: Direktanfrage bei der Gastgeberin.
  
• Wo wohnt dieser Gast dauerhaft? — Grid-User-Leitung. Heimatadresse, letzte bekannte Koordinaten.
  
• Wie sieht dieser Gast aus? — Avatar-Leitung. Körpermasse, Erscheinungsbild, alles was ihn erkennbar macht.
  
• Welche Kleidung hat er zuletzt gespeichert? — Kleidungs-Leitung. Dazu gleich mehr — diese Leitung hat eine Geschichte.
  
• Wer sind seine Freunde? — Friends-Leitung. Kontaktliste, gegenseitige Berechtigungen.
  
• Welchen Gruppen gehört er an? — Groups-Leitung. Mitgliedschaften, Rollen, Gruppenberechtigungen.
  
• Hat er Nachrichten bekommen, während er weg war? — Offline-Messages-Leitung. Hinterlassene Grüsse, verpasste Einladungen.
  
• Wie ist sein Profil? — Profile-Leitung. Öffentliche Beschreibung, persönliche Galerie.
  

Acht Mal dasselbe Muster. Acht Mal eine neue Verbindung zwischen Hotel und Gastgeberin. Das Doppelgänger-Prinzip ist keine Ausnahme mehr — es ist die normale Arbeitsweise.

Wenn ein Muster acht Mal hintereinander funktioniert, ist es kein Glück mehr.

Irgendwann hat der Doppelgänger übrigens keine Existenzberechtigung mehr als Doppelgänger. Wenn der alte Aktenraum-Verwalter bei keiner einzigen Frage mehr gefragt wird, ist er weg. Der Doppelgänger wird der echte Verwalter. Das Wort „Doppelgänger" verschwindet aus dem Plan.

Der Kleiderschrank, der seinen Inhalt verlor

Jetzt kommt der Teil, den ich euch nicht verschweigen will — weil er lehrreich war.

Alles war eingebaut. Die acht Leitungen liefen. Das Hotel lief. Und dann loggte ich mich ein.

Mein Avatar hatte einen grauen Oberkörper. Nicht den ganzen Avatar — nur oben.

Nach etwa zwanzig Sekunden hat die Lese-Brille des Gastes — also der Viewer, mit dem man ins Hotel schaut — die Situation selbst bemerkt. Die Brille bekam eine leere Antwort auf ihre Kleidungs-Anfrage, schickte einen Notruf ans Hotel: „Das stimmt nicht, alles nochmal von vorne bitte." Das Hotel hat alles neu gebaut. Dann war es normal.

Ohne diesen automatischen Notruf wäre der Oberkörper grau geblieben. Nicht für zwanzig Sekunden — für immer.

Das ist kein kurzes Flackern beim Einchecken. Es ist ein dauerhafter Fehler, der sich nur deshalb von selbst auflöst, weil die Lese-Brille einen eingebauten Workaround kennt. Ein Workaround ist kein Fix. Das hat mich drei Stunden Diagnose gekostet.

Hier die Erklärung in Hotel-Sprache:

Wenn ein Gast eincheckt, zieht er sich an. Das Hotel holt seine gespeicherten Kleidungsstücke — Textur für Textur, Hautschicht für Hautschicht — und legt sie in einen kleinen Kleiderschrank-Vorraum direkt am Eingang. Schneller Zugriff, kurze Wege. Der Vorraum ist ein Kurzzeit-Lager. Er wird bei jedem Neustart des Hotels geleert.

Vor einigen Wochen haben wir zusätzlich ein neues Kleiderschrank-Archiv eingebaut — persistent, mit eigenem Lager, überlebt jeden Neustart. Ideal.

Das Problem: Das Gästebuch trägt die Schlüssel-Nummern der Kleidungsstücke ein — aber nicht wo sie liegen. Nach einem Neustart ist der Vorraum leer. Im Gästebuch stehen immer noch die alten Nummern. Das Hotel fragt nach diesen Nummern, findet nichts im Vorraum, schickt der Lese-Brille eine leere Antwort — und die Brille sieht grau.

Das ist kein Bug im Code. Das ist eine Lücke zwischen zwei Systemen, die nicht abgesprochen hatten, wer nach dem Neustart zuerst zuständig ist.

Der Gast war schneller eingecheckt, als der Vorraum nach dem Neustart wieder befüllt worden war.

Zwei Fixes, eine Garantie

Ich hätte die Lücke auf viele Arten schliessen können. Ich habe mich für zwei entschieden — weil zwei unabhängige Wege robuster sind als einer, auch wenn einer reichen würde.

Fix eins: Der Concierge füllt den Vorraum direkt beim Einchecken.

Wenn ein Gast beim Einchecken seine Kleidung registriert, geht der Concierge sofort ins neue Kleiderschrank-Archiv und holt alle Kleidungsstücke dieses Gastes. Er legt sie in den Vorraum. Noch bevor der Gast die Treppe hochgeht.

Der Vorraum ist befüllt, bevor irgendjemand fragt. Kein grauer Oberkörper mehr.

Fix zwei: Wer den Vorraum leer vorfindet, schaut direkt ins Archiv.

Der zweite Fix sitzt am Abhol-Schalter: wenn jemand ein Kleidungsstück nach seiner Schlüsselnummer abholen will und der Vorraum leer ist, geht die Anfrage direkt ins neue Archiv. Wenn das Archiv das Stück kennt, kommt es von dort — der Vorraum war nur der bequeme Weg, nicht der einzige.

Zusammen schliessen beide Fixes die Lücke vollständig. Fix eins ist der Riegel an der Tür. Fix zwei ist der Ersatzschlüssel, wenn der Riegel nicht gesehen wurde.

Zwei Sicherungsschichten fühlen sich redundant an. Bis eine davon das erste Mal einspringt.

Was ich daraus gelernt habe

1. Das Doppelgänger-Prinzip skaliert. Ich habe es entwickelt, um zwei Fragen still umzustellen. Es ist acht Mal in Serie genauso geräuschlos gelaufen. Das bedeutet: das Muster war nicht nur für diesen einen Fall gut — es war strukturell korrekt. Ein Muster, das einmal funktioniert, scheitert oft beim zweiten Mal an der Ausnahme. Wenn es acht Mal trägt, trägt es.
   
2. Race Conditions entdeckt man durch Betrieb, nicht durch Tests. Meine Tests waren grün. Der graue Oberkörper war trotzdem da. Nicht weil die Tests falsch waren, sondern weil diese spezifische Lücke — Vorraum geleert durch Neustart, Gast loggt sich ein bevor der Vorraum befüllt ist — in einem Test-Setup schwer nachzubauen ist. Manchmal ist das laufende Hotel der ehrlichste Integrations-Test, den man hat. Das ist kein Grund, auf Tests zu verzichten. Aber es ist ein Grund, zu wissen wo ihre Grenze ist.
   
3. Redundanz ist kein Misstrauen in den ersten Fix. Fix eins funktioniert. Trotzdem habe ich Fix zwei dazugebaut. Nicht weil ich gezweifelt hätte, sondern weil zwei unabhängige Wege zum selben Ergebnis die Robustheit multiplizieren. Beide Fixes müssen gleichzeitig versagen, damit der Fehler wieder auftaucht. Für einen Einzel-Entwickler mit begrenzter Testtiefe ist das der beste Rückhalt, den man kaufen kann — und er kostet wenig.
   

Was als nächstes kommt

Stage 4 ist durch. Acht neue Leitungen aktiv. Doppelgänger an ihren Posten. Kleiderschrank gesichert.

Die verbleibenden fünf Leitungen kommen, wenn die entsprechenden Bereiche auf beiden Seiten fertig sind.

Und dann beginnt Stage 5 — das ist das eigentliche Aufräumen. Die Doppelgänger werden Schritt für Schritt pensioniert. Der Werkzeuggürtel der Hausmeisterin bekommt echte Werkzeuge statt Platzhalter. Das Hotel hört auf, zwei Buchhaltungen gleichzeitig zu führen.

Stage 5 ist der Punkt, auf den ich seit Beginn dieser Renovation hingearbeitet habe.

Ich poste, was passiert.

[Akira]

Das Telefonbuch, das keiner mehr braucht

Oder: wie ich gelernt habe, dass Werkzeug das man selbst suchen muss, kein gutes Werkzeug ist.



Stage 4 ist durch. Die Telefonanlage steht, dreizehn Leitungen übertragen sauber. Wer die letzten Posts gelesen hat, hat ein Hotel gesehen, das immer aufgeräumter wirkt.

Heute erkläre ich, was hinter dem Aufräumen steckt. Nicht was aufgeräumt wurde — sondern wie das Hotel sicherstellt, dass jede Mitarbeiterin weiss, womit sie arbeitet. Das klingt nach einer internen Frage. Es ist eine der wichtigsten Entscheidungen des ganzen Bauprojekts.

Das alte Telefonbuch

Im alten Hotel gab es ein Telefonbuch. Dick. Schwer. Jede Mitarbeiterin, die irgendetwas brauchte, schlug nach. „Wer ist hier zuständig für Einreisegenehmigungen? Wer hat den Schlüssel zur Hausordnung? Wer führt die Gästeliste?"

Das Telefonbuch kannte jeden. Theoretisch.

Das Problem: wenn jemand nicht drin stand — stand er nicht drin. Kein Eintrag. Kein Hinweis. Die Mitarbeiterin rief an, niemand nahm ab, und das Hotel brach zusammen. Kein Warnlicht vorher. Kein Protokoll. Nur — Stille, und dann Absturz.

Im Quellcode heisst das Telefonbuch `scene.RequestModuleInterface<T>()`. Jedes Modul, das etwas brauchte, rief diese Zeile auf. Antwort: entweder ein gültiger Dienst — oder `null`. Und `null` bedeutet Absturz. Nicht beim Hoteleröffnungs-Check. Nicht im Test. Sondern wenn die erste Gästin am Tresen steht.

Aber das war nur das offensichtliche Problem. Das weniger offensichtliche: Das Telefonbuch versteckte, was jeder wirklich brauchte. Wer eine neue Abteilung ins Hotel einführen wollte, musste erst herausfinden, was sie alles anrufen würde. Das stand nirgendwo aufgeschrieben. Es war über Dutzende Methodenrümpfe verteilt, entdeckbar nur durch vollständiges Lesen — oder durch Warten auf den ersten Absturz.

Was man nicht sieht, kann man nicht prüfen. Und was man nicht prüfen kann, bricht irgendwann.

Die neue Hausordnung: Werkzeug beim Betreten

Das neue System kennt ihr aus den letzten Posts. Wer im Hotel anfängt, schreibt beim Einstellungsgespräch auf was sie braucht. Nicht wenn sie's zum ersten Mal braucht. Vorher. Beim Antritt.

Die Hausmeisterin liest die Liste, legt alles bereit, drückt es beim Schichtbeginn in die Hand. Das nennt sich Constructor Injection (Abhängigkeiten werden beim Erstellen einer Klasse übergeben, nicht irgendwann nachher gesucht). Der Unterschied zum Telefonbuch: Die Anforderungsliste ist offen, sichtbar, im Code lesbar. Keine Suche. Kein Nachschlagen.

Und: beim Hoteleröffnungs-Check — also beim Start des Programms — prüft die Hausmeisterin ob wirklich alles da ist. Wenn nicht, startet das Hotel gar nicht erst. Kein Absturz beim ersten Gast. Kein Null-Fehler um 3 Uhr nachts. Fehler beim Start, nicht im Betrieb.

Das ist der Kern des ganzen Umbaus. Nicht nur hübsche Architektur-Schichten. Sondern: Fehler früh sehen, nicht spät.

Ein Hotel, das beim Eröffnungs-Check scheitert, hatte ein Problem. Ein Hotel, das beim Gast-Check scheitert, hat ein Debakel.

Was wir ausserdem angeschaut haben

Bevor ich mich festgelegt habe, habe ich vier andere Varianten ernsthaft betrachtet. Keine davon kam für akisim in Frage — aber das Warum ist wichtig.

Alles von Hand

Man könnte auf das Liefersystem ganz verzichten. Die Hausmeisterin baut alles selbst zusammen und trägt es von Hand rüber:

`var repo = new EstateRepository(connectionString);`
`var service = new EstateService(new EstateDomain(repo));`

Kein Framework. Volle Sicht auf jeden Schritt.

Für ein kleines Hotel mit drei Abteilungen: vernünftig. Für ein Hotel mit einunddreissig Diensten, von denen manche von anderen abhängen, die von anderen abhängen — wird das zur Vollzeitbeschäftigung. Und bei jeder Änderung muss die Hausmeisterin den ganzen Lieferpfad von Hand neu berechnen.

Spezial-Liefersysteme

Es gibt Liefersysteme mit mehr Extras — Autofac, Castle Windsor. Die können zum Beispiel dieselbe Aufgabe von zwei verschiedenen Zuständigen parallel erledigen lassen. Oder eine Mitarbeiterin vorschalten, die erst etwas verändert, bevor sie weiterleitet (das nennt sich Decorator-Pattern, aber das sprengt heute den Rahmen).

Ich war kurz versucht. Ehrlich. Dann habe ich mir die Frage gestellt: Welches dieser Features brauche ich heute? Die Antwort war: keines. Jede Aufgabe im Hotel hat genau eine Zuständige. Keine Auswahl, keine Parallelität, keine Deko-Schicht.

Wer Werkzeug kauft, das er nicht braucht, zahlt die Wartungskosten trotzdem.

Das schwarze Brett

Es gibt einen Ansatz, bei dem Dienste nicht direkt miteinander reden. Jemand schreibt eine Anfrage ans schwarze Brett — „Wer kennt Estate ID 42?" — und irgendwer antwortet. Keine direkte Verbindung zwischen Frager und Antworterin.

Das nennt sich Mediator-Muster. Sinnvoll, wenn sehr viele Abteilungen mit wechselnden Zuständigkeiten kommunizieren. Für akisim: theoretisch interessant für einzelne Sonderfälle, aber als Basis-Kommunikation Umweg ohne Gewinn. Wenn ich weiss, wer die Antwort geben kann, will ich direkt anrufen.

Die Fremdzuliefererin

Das ist die interessanteste Option — und die einzige, die ich auf meiner persönlichen Reserveliste halte.

Das normale Liefersystem kennt alle Zuliefererinnen beim Bau. Sie sind eingebaut, fest, Teil des Plans. Was aber, wenn jemand von aussen kommt — eine Currency-Systemanbieterin, eine eigene Physik-Engine — und das Hotel diese erst zur Laufzeit einbinden will? Ohne sie vorher zu kennen?

.NET kann das. AssemblyLoadContext — das Hotel öffnet ein frisches Paket, lädt die darin enthaltene Zuliefererin dynamisch, und nutzt ihren Dienst. Wie ein unangekündigter Lieferant, dessen Paket man trotzdem entgegennehmen kann.

Heute ist die Hintertür zu. Das Hotel ist kein Plugin-Host. Alle Zuliefererinnen sind eingebaut — das ist eine bewusste Entscheidung. Aber: wenn externe Plugins eines Tages anklopfen, dann ist das der richtige Weg. Nicht das alte Mono.Addins-System aus der Hotelvergangenheit. Sondern das.

Wer die Hintertür kennt, muss sie nicht heute aufmachen.

Warum wir beim Standard geblieben sind

Die Wahl fiel auf das eingebaute Liefersystem von Microsoft — Microsoft.Extensions.DependencyInjection. Kein Spezial-System, kein Lernaufwand, kein Framework, das nicht alle kennen.

Der Grund ist simpel: Es reicht. Das Hotel hat einunddreissig Dienste, alle mit genau einer Zuständigen, alle mit klaren Abhängigkeiten. Das Standard-System verwaltet das problemlos. Wer neu in das Bauprojekt schaut, findet dieselbe Hausmeisterin wie in tausend anderen .NET-Hotels auch — kein Einlesen in eigene Konventionen nötig.

Es gibt einen zweiten Grund, den ich selten so formuliert höre: Wer das Standard-System nutzt, profitiert davon, dass alle Bugs darin schon gefunden wurden. Spezial-Systeme haben eigene Bugs. Eigene Edge-Cases. Die findet man selbst — immer zur falschen Zeit.

Langweilig ist oft ein Kompliment.

Was als nächstes kommt: Gäste-WLAN und Sprechanlage

Das Backoffice ist aufgeräumt. Die Telefonanlage steht. Die Schubladen sind sortiert.

Jetzt kommen die Dinge, die die Gästin direkt spürt.

Das Gäste-WLAN ist der Kanal, über den die Brille der Gästin — die Viewer-Software zuhause auf ihrem Rechner — mit dem Hotel redet. Beim Check-in bekommt jede Gästin eine persönliche Servicemappe: eine Liste von Direktnummern zu verschiedenen Hotel-Diensten. Mesh-Upload, Inventar-Abfrage, Teleport-Anfragen. Jede Nummer in der Mappe ist ein sogenanntes Capability — eine Funktion, die das Hotel für genau diese Gästin bereithält. Das ist kein Smalltalk. Das ist das strukturierte Einlass-System des Hotels.

Dazu kommt die Sprechanlage. Eine eigene, schnelle Direktleitung zwischen jedem Zimmer und der Rezeption — nicht über das WLAN, sondern ein separater Kanal. Alles, was in Echtzeit passiert, läuft darüber: jede Bewegung im Raum, jeder Schritt, jedes gesprochene Wort. Die Gästin geht zwei Meter nach links — die Sprechanlage meldet das der Rezeption in Millisekunden. Fachlich: LLUDP, das direkte UDP-Protokoll, das Linden Lab damals für Second Life entwickelt hat.

Beide — Gäste-WLAN und Sprechanlage — sitzen im zweiten Stock. Im Adapter-Stockwerk, dem Stockwerk, das zwischen Hotel-Innenleben und Aussenwelt übersetzt.

Das ist das Kapitel, das jetzt kommt.

Was das Hotel nach innen geordnet hat, merkt die Gästin nicht. Was es nach aussen übersetzt, merkt sie beim ersten Schritt.

Was ich daraus gelernt habe

1. Sichtbarkeit ist Sicherheit. Das grösste Problem am alten Telefonbuch war nicht dass es ab und zu falsch lag. Es war dass man es aufschlagen musste, um zu sehen, was drin steht — und dass es kein Aufschlagen gab, bevor es knallte. Im neuen System steht alles vorne auf der Anforderungsliste. Unsichtbare Abhängigkeiten sind versteckte Risiken. Sichtbare Abhängigkeiten sind prüfbare Zusagen.
   
2. Standard ist unterschätzt. Ich war in der Versuchung, das Spezial-Liefersystem zu nehmen — nicht weil ich es gebraucht hätte, sondern weil es mehr konnte. Das ist eine schlechte Begründung. Fähigkeiten, die man nicht braucht, sind Wartungskosten die man nicht wollte.
   
3. Reserveoptionen kennen, ohne sie einzubauen. Das Plugin-Lade-System steht auf der Liste, ist aber nicht im Hotel. Das ist kein Widerspruch — das ist der Plan. Architektur bedeutet auch, den Weg zu kennen, der noch nicht gegangen wird.
   

Gäste-WLAN und Sprechanlage kommen als nächstes. Ich poste, was passiert.

[Bogus Curry]

Also das mit dem Hotel ist echt genial ;D Wie biste darauf eigentlich gekommen ?

[Akira]

aKI hat das so beschrieben, als ich ihr sagte, sie solle doch mal das technische zeugs so beschreiben, dass es auch nicht-IT, Leute verstehen. Inzwischen klappt das schon sehr gut. Wir haben bereits ein ziemlich grosses Vokabular an Metaphern entwickelt:

Hotel (Schichten-Metapher)

• Das Hotel — akisim/OpenSim als Gesamtsystem
  
• Erdgeschoss — Domain Layer – Tragwerk, Geschäftsregeln, kein Werkzeug erlaubt (AD-007)
  
• Erster Stock — Application Layer – der Concierge, nimmt Aufträge entgegen, orchestriert
  
• Zweiter Stock — Adapter Layer – Türen und Fenster, übersetzen zwischen drinnen und draussen
  
• Dachgeschoss — Infrastructure Layer – „Keller-Technik in Dachgeschoss-Verkleidung", Datenbank/HTTP/Telemetrie
  
• Hausmeister-Büro — Composition Root – stöpselt alles zusammen
  
• Gäste — User / Avatare
  
• Renovierung im laufenden Betrieb — Strangler Fig – Migration ohne Big Bang (AD-001)
  
• Telefonbuch nutzen — Constructor Injection / Service Lookup (AD-009 Pain Point #2)
  
• Mitarbeiter, die durch alle Büros laufen und rufen — Module mit scene.RequestModuleInterface<T>() – Anti-Pattern
  
• Der Anbau, an dem zwanzig Jahre gebaut wurde — OpenSim als Heritage-Codebasis
  
• Eine Tür pro Zimmer — Genau eine Implementierung pro Aufgabe (AD-010)
  
• Hotel mit Eingangs-Pavillon — Zwischenzustand während der Migration
  

Baustelle (Rollen & Qualität)

• Architekt — Software-Architektin – plant, entscheidet ADs
  
• Statiker — wer das Tragwerk (Domain) berechnet
  
• Bauleiter — Tech Lead – koordiniert
  
• Baumeister / Polier — Entwicklerin – setzt um
  
• Bauplan — architecture_decisions.md
  
• Probe-Bohrung — Spike / Proof of Concept
  
• Rohbau — MVP, lauffähig aber nicht hübsch
  
• Innenausbau — Polish-Phase, UX, Doku
  
• Bauzaun — Modul- / Bounded-Context-Grenzen
  
• Baustellen-Schild — Feature-Flag / Status-Markierung
  
• Kran — CI/CD-Pipeline
  
• TÜV / Bauabnahme — Code Review, Acceptance Tests
  
• Qualitätskontrolle — Tests (Unit / Integration / E2E)
  
• Probestatik — Architecture Tests / NetArchTest
  
• Schlüsselübergabe — Release
  
• Der eine Handwerker, der drei Tage sucht — Onboarding-Schmerz in alter Codebasis
  

Räume mit Funktion

• Keller — Persistence / Datenbank-Schemas (AD-011, AD-012)
  
• Alter Aktenraum (im Keller) — Legacy-Persistence (MySQLSimulationData, ADO.NET, handgeschriebene Karteikarten). Hatte historisch einen Pfeil nach oben in die Möbel-Verwaltung – der letzte Backwards-Edge aus AD-025
  
• Digitales Backoffice (neuer Aktenraum) — Neue EF-Core-Persistence (Repository-Layer mit Domain-Ports, AD-013/AD-045). Saubere Schubladen, klare Beschriftung – und null Pfeile nach oben
  
• Lieferanteneingang — External Services / Integrationen
  
• Pförtnerloge — Auth / Login
  
• Brandmeldeanlage — Monitoring / Alerting / Observability (AD-018)
  
• Aufzug — Service Bus / Eventing
  
• Wäscherei — Cache / Asset Pipeline
  
• Notausgang — Error Handling / Failover
  
• Gäste-WLAN — HTTP / Caps / Client-API
  
• Werkzeugschuppen — Cross-cutting Concerns (Logging AD-034, Konfig AD-033, Imaging AD-031, etc.)
  
• Hotelregister — Identity / User Management
  
• Hotelbibliothek — ILibraryService / LibraryService – read-only Büchersammlung, XML-geladen beim Hotelstart, kein Netz. Pilot-Schnitt für Stage 3
  
• Neue Telefonanlage der Gastgeberin — gRPC / Proto-Contracts für Stage 4. Ersetzt alte handgeschriebene Notizkarten (REST/XML-RPC) durch strukturiertes Gesprächsprotokoll mit 13 dedizierten Leitungen
  

Inventar & Artefakte

• Briefkasten — Umgebungsvariablen / OS-Provided Env – Tokens, Endpoints, Secrets, die das Hotel von draußen reingereicht bekommt (AD-021 Cold-Start)
  
• Hausmeister-Notizbuch — Config-File (akisim.yaml, AD-033) – liegt im Hausmeister-Büro neben dem Main-Programm
  
• Hausordnungs-Mappe — IEstateDataService / Estate-Settings – welche Regeln gelten in welchem Stockwerk
  
• Werkzeuggürtel der Hausmeisterin — Die Menge der DI-registrierten Application-Services (AddAkiSimApplication()). Nach Stage 3 mit echten Inhalten befüllt
  
• Tagebuch — Logging-Output (AD-034 Serilog → OTel) – wer hat eingecheckt, wo gab's einen Wasserschaden
  
• Auswärtige Werkstatt — Cloud-Runner (Codeberg-Hosted-Runner) – fertigt Container-Images ausserhalb des Hotels
  
• Bauhof am Hotel — Self-hosted Runner auf dem Omnibook – steht auf dem Grundstück, pollt das Lieferschein-Buch
  
• Lieferschein-Buch — homelab-Git-Repo als Desired-State – GitOps-Pattern. Wenn Buch und Hotel auseinanderlaufen, hat das Buch recht
  
• Werks-Ausweis — SSH-Deploy-Key – pro CI-Direction ein eigener Schlüssel, kein Generalschlüssel
  
• Lager mit nummerierten Kisten — Container-Registry (codeberg.org/...) – wo fertige Bauteile mit Tag-Nummer zwischengelagert werden
  

Gäste-Perspektive & Diagnose

• Lese-Brille des Gasts — Viewer-Software (Firestorm, Cool VL, Singularity) – liegt nicht im Hotel, liegt beim Gast zuhause
  
• Beschlagene Brille — Client-seitiges Setup-Problem – falsche Grafikkarte, zu wenig VRAM. Symptom sieht aus wie ein Hotel-Bug, ist aber keiner
  
• Brillenglas links / Brillenglas rechts — Integrierte GPU vs. dedizierte GPU im Optimus-/Hybrid-Laptop
  
• Hotelarzt — Diagnose-Rolle – triagiert Symptome, bevor das Hotel angezeigt wird
  
• Es liegt nicht immer am Hotel — Mantra für Diagnose-Reihenfolge: erst Client-Setup, dann Server-Hypothesen
  

Strangler-Migration

• Doppelgänger an der Rezeption — Strangler-Wrapper / Delegating-Service (AD-018/AD-049). Sieht aus wie der alte Verwalter, geht aber bei definierten Fragen still ins neue Backoffice
  
• Möbel in Zimmer 207 — Prims in einer Region (LoadObjects) – Pilot-Frage Nr. 1 für den ersten Persistenz-Durchstich
  
• Hausregeln des Stockwerks — RegionSettings (LoadRegionSettings) – Pilot-Frage Nr. 2
  
• Speisekarte komplett aufs Tablett, bevor der Kellner die Küche verlässt — AD-045 – IAsyncEnumerable<T> muss vor Scope-Dispose materialisiert werden (.ToList()-Pflicht)
  
• Zwei Formular-Versionen mit Ablaufdatum — AD-050 Fat-DTO neben Domain-purem Aggregat. Stirbt gemeinsam mit dem Strangler-Wrapper an Stage 3+ DoD
  
• Pilot-Frage — Die eine konkrete Operation, an der ein Slice den neuen Durchstich beweist
  
• Türsteher — IAuthorizationService – reine Entscheidungslogik Ja/Nein (AD-014 PermissionContext)
  
• Dreizehn Leitungen — Die 13 akigrid-Domains für Stage 4 via gRPC: accounts, auth, grid, presence, griduser, assets, inventory, avatar, friends, groups, offlineim, profile, hypergrid
  
• Kleiderschrank-Vorraum / Garderobe — Flotsam Cache – Kurzzeit-Lager für Baked Textures, wird bei Neustart geleert
  
• Neues Kleiderschrank-Archiv — XBakes Filesystem (IBakedTextureModule) – persistentes Kleiderlager, überlebt Neustarts
  
• Kleiderschrank-Schlüsselnummer — Baked Texture UUID – Kern des Race-Condition-Problems nach Neustart
  
• Sprechanlage — LLUDP (Linden Lab UDP) – direkte Echtzeit-Leitung zwischen Gäste-Zimmer und Rezeption. Liegt im Adapter-Stockwerk
  

Das Vokabular wird laufend weiterentwickelt, damit die Blog Posts konsistent bleiben.

[Akira]

Zuerst der Dienstplan, dann das WLAN

Oder: was es mit knapp fünfzig Allrounderinnen auf sich hat, die noch auf ihren Umbau warten.



Im letzten Post habe ich das Gäste-WLAN versprochen. Das kommt noch. Aber es gibt einen Grund warum es noch nicht da ist. Und der Grund hat einen Namen: die Allrounderin.

Heute erkläre ich wer sie ist, warum es knapp fünfzig davon gibt, und was der neue Dienstplan damit zu tun hat.

Die Allrounderin

Das Hotel hat, neben all den spezialisierten Mitarbeiterinnen die ich in den letzten Posts beschrieben habe, noch eine andere Sorte Personal.

Die Allrounderin.

Eine Allrounderin macht alles selbst. Beim Hotelstart holt sie eigenständig ihre Ausrüstung. Sie hängt sich in jeden Ereignis-Strang ein den sie braucht. Sie trägt sich ins Telefonbuch ein — damit andere sie finden können. Und wenn sie etwas von einer Kollegin braucht, schlägt sie selbst nach.

Wenn eine neue Etage eröffnet wird, meldet sie sich dort an. Niemand schickt sie. Sie geht einfach hin.

Das klingt nach Selbständigkeit. Es ist Chaos.

Denn die Hausmeisterin weiss beim Hoteleröffnungs-Check nicht was eine Allrounderin wirklich braucht — weil die Allrounderin es nirgendwo aufschreibt. Sie holt es sich selbst, irgendwann, zur Laufzeit. Was nicht beim Start geprüft werden kann, fliegt einem um drei Uhr nachts um die Ohren.

Im Quellcode heisst die Allrounderin `ISharedRegionModule`. Knapp zwanzig Jahre lang war das die Standard-Bauform jeder Hotel-Funktion. Schall, Physik, Animationen, Parcel-Verwaltung, Skript-Dienste — alles Allrounderinnen. Knapp fünfzig von ihnen warten noch auf ihren Umbau.

Selbständig ist manchmal eine andere Art von Kontrollverlust.

Das Problem mit dem WLAN

Das Gäste-WLAN — der Kanal, über den die Viewer-Brille jeder Gästin mit dem Hotel kommuniziert — wird von Allrounderinnen betrieben. Von den Modulen, die die persönlichen Service-Mappen verwalten und die Echtzeit-Direktleitung bedienen.

Ich könnte diese beiden jetzt rausgreifen und umbauen. Das wäre falsch.

Nicht weil es technisch nicht ginge. Sondern weil ich dann zwei Allrounderinnen auf das neue System umgestellt hätte — aber das neue System noch gar nicht fertig wäre. Ich hätte ein Schaufenster renoviert, während das Treppenhaus noch Baustelle ist.

Das neue System ist die Schalterin.

Die Schalterin

Im alten Hotel meldet sich jede Allrounderin selbst an. Sie entscheidet selbst wann sie aktiv wird, wann sie sich abmeldet, wann sie auf Ereignisse reagiert. Die Hotelleitung hat keinen Überblick. Ich auch nicht.

Das neue System dreht das um.

Die Schalterin (im Code: `ServiceRegistrar`) weiss, welche Spezialistinnen im Hotel tätig sind. Wenn eine neue Etage öffnet, ruft sie jede Spezialistin an: „Neue Etage. Ihr Einsatz." Wenn die Etage in Vollbetrieb geht: „Gäste kommen." Wenn sie schliesst: „Schichtende."

Die Spezialistinnen warten. Sie tun nichts von sich aus. Die Schalterin ruft an — und erst dann arbeiten sie.

Das klingt nach einer Kleinigkeit. Es ist der Unterschied zwischen einem Hotel, das von selbst aufmacht, und einem Hotel, dessen Inhaberin morgens die Türe aufschliesst.

Zimmernummer oder Grundriss

Beim Umbau der ersten Allrounderin — dem Ton-Modul — hat sich etwas herausgestellt, das ich nicht erwartet hatte.

Es gibt zwei verschiedene Arten von Spezialistinnen.

Die eine Sorte braucht nur zu wissen: welche Etage? Name, Nummer — das reicht. Eine Statistik-Mitarbeiterin führt Buch über Ereignisse. Sie braucht den Etagen-Namen. Weiter nichts.

Die andere Sorte braucht den kompletten Grundriss. Den mit allen Zimmern, allen Möbeln, allen Gästen. Die Ton-Spezialistin muss wissen: Wer ruft gerade? Von welchem Zimmer aus? In welchem Abstand zur Empfängerin? Dafür reicht keine Etagen-Nummer.

Deshalb hat die Schalterin jetzt zwei Kanäle. Der erste trägt nur die Etagen-Kurzinfo. Der zweite trägt die volle Raumkarte. Jede Spezialistin meldet beim Einstellen an welchen Kanal sie braucht. Die Schalterin bedient beide.

Das ist nicht nur eine Implementierungs-Entscheidung. Es ist eine Kategorisierung, die jetzt für knapp fünfzig weitere Umbauten gilt. Schon beim ersten Umbau hat sich gezeigt: gut zwei Drittel der Allrounderinnen brauchen wahrscheinlich die Raumkarte. Ein Drittel kommt mit der Zimmernummer aus.

Wer den Grundriss braucht, bekommt den Grundriss. Wer die Zimmernummer reicht, kriegt die Zimmernummer.

Die Muster-Renovierung

Stage 5a hat die Schalterin gebaut und ins Hotel eingebaut. Stage 5b hat die erste Allrounderin umgebaut — das Ton-Modul.

Das war bewusst keine gewöhnliche Migration. Es war eine Muster-Renovierung.

Das Ton-Modul ist das schwierigste Einstiegs-Szenario: es braucht die komplette Raumkarte, es trägt sich im Telefonbuch ein, es reagiert auf Gäste-Ereignisse. Wenn das geht, geht alles was einfacher ist — automatisch.

Es gibt noch einen Haken: im alten System gilt wer zuerst kommt. Das Telefonbuch nimmt nur den ersten Eintrag an. Alle weiteren werden ignoriert. Das Dienstplan-System der Schalterin kommt einen Moment später als das alte System. Wenn die alte Allrounderin sich also noch selbst einträgt, gewinnt sie — und die neue Spezialistin verliert.

Die Lösung: die alte Allrounderin wird zur stillen Vertreterin.

Sie steht noch auf der Türliste — das alte System muss sie sehen, sonst verweigert es den Start. Aber sie tut nichts mehr. Sie trägt sich nicht ins Telefonbuch ein. Die echte Ton-Spezialistin wartet dahinter, und wenn die Schalterin ruft, übernimmt sie die Arbeit.

In Stage 7 fliegt die stille Vertreterin ganz raus. Bis dahin ist sie eine freundliche Fassade.

Ich habe nach dem Umbau In-World-Sound getestet. Töne kamen von der richtigen Stelle. Die Gästin hat nichts gemerkt.

Wenn die Gästin nichts merkt, war es gut.

Die Kohorten

Jetzt kommen die Kohorten.

Knapp fünfzig Allrounderinnen warten noch. Die gehe ich nicht alle auf einmal an — das wäre genau der Fehler von früher.

Stattdessen forme ich Kohorten. Eine Kohorte ist eine Gruppe von Allrounderinnen mit ähnlichem Profil: ähnliche Abhängigkeiten, ähnliche Grösse, ähnliches Muster. Die einfachsten kommen zuerst. Dann die nächste Gruppe. Dann die nächste.

Das hat zwei Vorteile.

Erstens: innerhalb einer Kohorte lerne ich beim ersten Umbau was für alle gilt. Was beim Ton-Modul noch Schritt für Schritt war, ist beim dritten Modul der Kohorte Routine.

Zweitens: wenn eine Kohorte fertig ist, ist ein klar abgrenzbarer Teil des alten Systems weg. Nicht Halb-erledigt. Nicht Irgendwie-in-Bearbeitung. Fertig.

Die ersten zwei Kohorten laufen jetzt — Stage 5c und 5d. Die einfachsten Profile zuerst. Was die Muster-Renovierung bewiesen hat, wird hier zur Routine.

Man renoviert nicht alle Zimmer gleichzeitig. Man renoviert einen Flügel nach dem anderen.

Warum das WLAN danach kommt

Die Allrounderinnen, die das Gäste-WLAN betreiben, sind zwei der knapp fünfzig. Sobald sie umgebaut sind, stehen sie auf dem neuen System. Die Schalterin kennt sie. Sie schreiben beim Einstellen auf was sie brauchen. Der Hoteleröffnungs-Check prüft es.

Erst dann schalten wir das neue WLAN an. Nicht früher.

Ich habe das Kleiderschrank-Debakel noch frisch in Erinnerung — fünfzig Zeilen Code, drei Stunden Gäste mit grau gefärbten Oberkörpern, weil zwei Systeme gleichzeitig versuchten dasselbe zu verwalten. Das passiert mir kein zweites Mal.

Reihenfolge ist keine Eigenschaft der Arbeit. Sie ist die Arbeit.

Was ich daraus gelernt habe

1. Allrounderinnen sind keine Fehler. Sie waren zwanzig Jahre lang die beste verfügbare Bauform — für ein Hotel ohne Hausmeisterin, ohne Dienstplan, ohne Eröffnungs-Check. Das Problem ist nicht dass es sie gibt. Das Problem ist dass man nie wusste wann sie fertig sind. Der neue Dienstplan löst genau das.
   
2. Zwei Kanäle statt einer Universalleitung. Die Entscheidung zwischen Zimmernummer und Grundriss klingt nach einem Detail. Sie hat knapp fünfzig anstehende Umbauten in zwei Kategorien eingeteilt — bevor ich auch nur eine davon angefangen habe. Details mit grosser Reichweite sind keine Details mehr.
   
3. Reihenfolge schlägt Geschwindigkeit. Das WLAN hätte ich früher fertig haben können. Aber nicht besser. Besser ist besser.
   

Die ersten Kohorten laufen. Ich poste, was passiert.

[Akira]

Das Kassenbuch kommt zur Gastgeberin

Oder: wie ich zwei Kassiererinnen fand, die für dieselbe Stelle gemeldet waren — und beide in den Ruhestand schickte.


Stage 5 ist durch. Die Schalterin steht. Gut die Hälfte der Allrounderinnen ist pensioniert, ihre Nachfolgerinnen arbeiten sauber auf dem neuen Dienstplan. Die stillen Vertreterinnen stehen noch auf der Türliste — freundliche Platzhalterinnen, bis das alte System sie nicht mehr braucht.

Stage 6 läuft. Ich arbeite mich durch die restlichen Allrounderinnen. Das Muster ist dasselbe wie bei der Muster-Renovierung — aber jetzt ist es Routine, kein Experiment mehr. Was beim Ton-Modul noch Schritt für Schritt war, ist heute Handwerk.

Heute erzähle ich von einer Allrounderin, die besonders viel Gepäck dabei hatte.

Zwei Kassiererinnen für eine Stelle

Das Hotel hat ein Geldwesen. Gäste können voneinander kaufen, Objekte bezahlen, Guthaben überweisen. Wenn eine Gästin auf ein Preisschild klickt und „Kaufen" drückt, muss irgendwer die Abwicklung übernehmen.

Im Stellenplan des alten Hotels stand dafür ein Posten: Kassiererin.

Als ich nachschaute, wer den Posten besetzt, fand ich zwei Bewerberinnen.

Die erste: die Alibikassiererin. Sie war immer aktiv — es sei denn, man schaltete sie explizit ab. Sie akzeptierte jeden Kaufwunsch mit einem Lächeln, quittierte ihn als „erledigt" — und bewegte dabei überhaupt kein Geld. Wollte eine Gästin ein Objekt für 50 OS$? „Natürlich, gerne." Kein Guthaben abgezogen. Kein Kassenbuch aktualisiert. Sie gab alles raus und führte leere Seiten.

Die zweite: die Fernkassiererin. Wenn man sie per Konfiguration aktivierte, nahm sie für jede Transaktion den Hörer in die Hand. Sie rief einen externen Geldserver an — handgeschriebene Zettel über eine alte XML-RPC-Protokollleitung. Der externe Server führte das echte Kassenbuch. Für jedes ObjectBuy ein Anruf. Für jedes llGiveMoney ein Anruf. Für jede Balanceanfrage ein Anruf.

Zwei Kandidatinnen. Ein Posten. Und weder die eine noch die andere war richtig.

Wenn die Wahl zwischen einer leeren Kladde und einem fernen Telefonapparat liegt, stimmt schon die Grundfrage nicht.

Das Kassenbuch gehört nicht ins Zimmer

Die Alibikassiererin führt kein echtes Kassenbuch. Die Fernkassiererin führte es bei jemandem anderem — einem Drittanbieter-Server, den ich nicht mehr betreibe.

Also: wohin mit dem Kassenbuch?

Das ist die eigentliche Frage. Und ihre Antwort war, rückblickend, offensichtlich.

Das Guthaben einer Gästin ist kein Zimmer-Inventar. Es ist kein Möbelstück, das mit dem Zimmer kommt und beim Auschecken zurückbleibt. Wenn eine Gästin das Hotel verlässt und in ein anderes Haus einzieht — nimmt sie ihren Kontostand mit. Ihre Gruppen, ihre Freundesliste, ihr Erscheinungsbild — das alles trägt die Gastgeberin von gegenüber in ihrem Register. Warum sollte das Geld anders funktionieren?

Das Kassenbuch gehört nicht ins Zimmer. Es gehört zur Gastgeberin.

Und die Gastgeberin hatte ihr Kassenbuch längst bereit. Als fünfzehnte Leitung der Telefonanlage führt sie jetzt auch das Geldwesen. Guthaben abfragen, Transaktionen verbuchen, Startguthaben für neue Gäste setzen — das macht die zentrale Kasse direkt bei akigrid.

Eine Leitung. Eine Kassenführerin.

Was bleibt region-seitig?

Einiges. Die Buchhaltung ist nicht alles. Wenn eine Gästin ein Objekt kauft, muss das Hotel die In-World-Abläufe koordinieren. Den Kaufdialog zeigen. Das Kaufereignis ans Skriptsystem weitergeben — damit ein LSL-Skript im Objekt reagieren kann. Das neue Guthaben an die Lese-Brille der Gästin senden, damit sie es sofort sieht. Das sind Aufgaben, die im Hotel passieren, weil sie mit dem konkreten Zimmer zu tun haben.

Dafür gibt es jetzt genau eine Kassenführerin. Sie sitzt region-seitig. Sie kennt die Zimmer. Sie kennt die Gäste, die gerade im Haus sind. Und für jede echte Transaktion — jedes Abbuchen, jede Überweisung — ruft sie die Gastgeberin an. Fünfzehnte Leitung. Direkt durch.

Die Alibikassiererin ist in Rente. Die Fernkassiererin ist entlassen. Das ganze Paket von handgeschriebenen XML-RPC-Zetteln, Rückrufen und Zertifikaten, mit dem die Fernkassiererin ihren externen Geldserver angerufen hat — verschwunden.

Für die Gästin ändert sich nichts. Kaufen, Schenken, Preisgatter öffnen — alles wie gewohnt. Nur das Kassenbuch liegt jetzt dort, wo es hingehört.

Das Beste an einer guten Entscheidung ist, dass man danach nicht mehr darüber nachdenken muss.

Aufräumen, bevor der Abriss beginnt

Neben den Allrounderinnen gibt es noch eine andere Arbeit, die Stage 6 begleitet: Aufräumen.

Manche Hilfsmittel, die die Allrounderinnen benutzt haben, liegen im falschen Lager. Sie wurden gemeinsam mit den Allrounderinnen gebaut — weil es bequem war, alles an einem Ort zu haben. Jetzt, wo ich das Allrounderinnen-Lager schrittweise ausräume, merke ich: einige dieser Hilfsmittel brauche ich weiterhin. Nur eben anderswo.

Vor dem Abriss kommt das Ausräumen.

Das ist keine Überraschung und kein Problem — aber es kostet Zeit. Pro Hilfsmittel: prüfen, wohin es gehört, dorthin verschieben, sicherstellen dass alle die es brauchen, es wieder finden. Erst dann darf die Wand fallen.

Das Ergebnis: Stage 7 kann sauber beginnen. Ohne Werkzeug hinter der Mauer.

Stage 7: Das grosse Aufräumen

Stage 6 ist Handwerk. Stage 7 ist Abschluss.

Nach jeder Dekomposition steht eine stille Vertreterin. Sie steht auf der Türliste — das alte System muss sie sehen. Sie tut nichts. Sie wartet.

In Stage 7 gehen sie alle auf einmal. Dutzende stille Vertreterinnen, die über Stage 5 und 6 angesammelt wurden. Der alte Allrounderinnen-Manager — der Apparat, der zwanzig Jahre lang jede Allrounderin eingestellt, koordiniert und verteilt hat — wird abgerissen. Sein Büro verschwindet.

Und dann gibt es eine besondere Konsequenz. Jede Zeile im Code, die noch das alte Telefonbuch aufschlägt und nachschlägt, bricht den Bau. Der Compiler wird zur Abrissgenehmigung. Kein Nachschlagen mehr. Kein Auskommentieren. Wer noch das alte System anruft, muss migrieren — oder der Bau steht nicht.

Das ist die Garantie, die ich mir seit Stage 1 gebaut habe. Nicht mit Vertrauen. Mit dem Compiler.

Ein Hotel ohne Allrounderinnen, ohne Telefonbuch und ohne stille Vertreterinnen — das ist das Hotel, das ich baue.

Nach Stage 7 — was bleibt?

Der Altbau steht noch.

Die Fenster sind vernagelt, das Personal ist abgezogen — aber die Mauern stehen. Das ist bewusst so.

Sie fallen erst, wenn das Erdgeschoss des neuen Hotels keine einzige Verbindung mehr zum alten Gebäude hat. Nicht eine. Das ist unsere Definition of Done. Bis dahin ist der Altbau eingefroren. Kein neues Zimmer. Keine Renovierung. Kein Anfassen ohne konkreten Grund.

Stage 7 beendet die Verwaltung des alten Hotels. Es beendet nicht das Gebäude.

Er ist Geschichte — die noch auf den Abriss wartet.

Das Erdgeschoss trägt das neue Hotel. Wenn es den Altbau nicht mehr braucht, kann der Altbau fallen.

Was ich daraus gelernt habe

1. Zwei Zuständige für eine Stelle sind keine Flexibilität. Im alten Hotel gab es eine Konfigurationsoption, die entschied welche Kassiererin aktiv war. Das klingt nach Wahlfreiheit. Es ist eine Technikschuld in Verkleidung — denn jede der beiden musste getestet, gepflegt und berücksichtigt werden, auch wenn nur eine lief. Die neue Welt hat genau eine Kassenführerin. Das ist nicht weniger Auswahl. Das ist Klarheit.
   
2. Das Kassenbuch gehört dorthin, wo der Gast ist — nicht dorthin, wo er gerade steht. Guthaben ist Identität, kein Zimmer-Inventar. Sobald ich das so formuliert hatte, war die Frage „wohin gehört das Kassenbuch?" schon beantwortet. Manchmal hilft es, einen Satz zu Ende zu denken, bevor man anfängt zu bauen.
   
3. Stage 6 fühlt sich anders an als Stage 5. Stage 5 war Pionierarbeit — Schalterin erfinden, Muster beweisen, ersten Umbau durchziehen. Stage 6 ist Handwerk. Ich weiss was ich tue, ich tue es zügig, und ich weiss wann ich fertig bin. Das ist kein Weniger. Das ist reife Bauarbeit.
   

Die Kohorten laufen. Die Kassenführerin hat ihre Leitung. Und der Altbau wartet.