Maxine hat in ihrem Leben schon oft versucht, Menschen ohne technischen Hintergrund zu erklären, wie beängstigend Code-Merges sind. Oft benutzt sie dann das Beispiel eines Hollywood-Drehbuchs, an dem 50 Autoren gleichzeitig arbeiten, obwohl noch unklar ist, wer die Hauptfigur sein oder wie das Ende des Films aussehen und ob es sich um einen düsteren Krimi oder um eine Krimikomödie mit stümperhaftem Detektiv plus Sidekick handeln soll.
Dann wird die Schreibarbeit zwischen allen Autoren aufgeteilt, und jeder von ihnen arbeitet isoliert an seinem Teil des Drehbuchs, wochenlang. Dann, kurz bevor das Drehbuch fertig sein muss, treffen sich alle 50 Autoren in einem Raum, um ihre gesamte Arbeit wieder zu einer einzigen Geschichte zusammenzufügen.
Natürlich wird jeder Versuch, ihre Drehbuchanteile miteinander zu verschmelzen, in einer Katastrophe enden. Man hat sich immer noch nicht auf die Hauptfigur geeinigt, es gibt Hunderte von zusätzlichen Charakteren, völlig unzusammenhängende Szenen und klaffende Löcher in der Handlung – um nur einige der Probleme zu nennen.
Außerdem haben die meisten Autoren das zwischenzeitliche Memo der Produzenten nicht gelesen, in dem es hieß, dass sie die Geschichte aufgrund des sich wandelnden Publikumsgeschmacks zu einem Horrorfilm mit riesigen Unterwassermonstern machen würden.
Code zusammenzuführen, ist genauso schwierig. Die Bearbeitung von Programmcode kann man nicht mit etwa der gemeinsamen Bearbeitung von Dateien in Google Docs vergleichen, wo alle Beteiligten sofort die Änderungen der anderen Beteiligten sehen können. Entwickler erzeugen stattdessen, wie Drehbuchautoren, eigene Arbeitszweige bzw. Stränge des Quellcodes, ihre eigene private Kopie – sogenannte Branches. Wie die hypothetischen Drehbuchautoren arbeiten Entwickler wochen-, manchmal auch monatelang isoliert vor sich hin.
Moderne Softwareversionsverwaltungen verfügen über Werkzeuge zur Automatisierung des Merge-Prozesses, aber wenn viele Änderungen vorliegen, werden ihre Grenzen nur allzu deutlich. Es kann vorkommen, dass jemand anderer die eigenen Änderungen überschreibt oder dass ein Developer etwas ändert oder löscht, von dem anderer Code abhängt, oder dass mehrere Personen widersprüchliche Änderungen an denselben Teilen eines Programms vornehmen – um nur einige der Dinge zu nennen, die schiefgehen können.
Maxine bevorzugt es, wenn alle ihre Änderungen möglichst häufig in den »Master-Branch« einbringen, den Hauptstrang der Codeentwicklung, beispielsweise einmal am Tag. Auf diese Weise werden Anzahl und Umfang der zusammenzuführenden Änderungen von vornherein begrenzt. Kleine Batch-Größen, wie in der Fertigung, sorgen für einen reibungslosen Arbeitsablauf ohne größere Störungen oder Katastrophen.
Ganz anders sieht es dagegen beim Phoenix-Projekt aus – 100 Entwickler arbeiten wochenlang, ohne zwischendurch ihre Änderungen zu mergen, und Purnas Auskunft zufolge dauert das Zusammenführen normalerweise mindestens drei Tage. Maxine ist sich sicher: Wer würde jemals so arbeiten wollen?
Sie geht zusammen mit Kurt und Purna zum »Merging War Room« in Gebäude 5 zurück, ein ihrer Meinung nach sehr passender Name. Als sie ihn betritt, läuft sie praktisch frontal gegen eine Wand feuchter Luft – zu viele Menschen in einem heißen, überfüllten Raum. Sie schaut sich um und versichert Kurt: »Es ist mir egal, was Kirsten sagt. Wir haben keine Chance, heute auch nur ansatzweise einen Release-Branch fertigzustellen.«
Purna geht zur Vorderseite des Raums und holt ihren Laptop heraus. Auf dem Weg zurück von QA hat Maxine erfahren, dass Purna als Integrationsmanagerin fungiert, die dafür verantwortlich ist, dass alle versprochenen Funktionen und Fixes den Weg in den QA-Release-Branch finden. Alle nennen sie liebevoll den »Merge-Boss«.
Maxine schaut sich den Tabellenausdruck an, den Purna ihr gegeben hat. Es gibt 392 Dev-Tickets, die gemergt werden sollen. Jede Zeile enthält eine Ticket-Nummer aus dem Dev-Ticketing-Tool, eine Beschreibung des Problems, eine Checkbox, die anzeigt, ob die Lösung gemergt wurde, einen Link zum QA-Testplan, die QA-Ticket-Nummer und so weiter.
Purna ist dafür verantwortlich, dass all diese Änderungen zusammengeführt werden, damit QA sie schließlich als Ganzes testen kann, um zu melden und zu überprüfen, ob die bekannten Mängel behoben wurden. Ein aufwendiger und oft undankbarer Job.
Maxine schnappt sich mit Kurt einen Platz im hinteren Teil des Raums. Um einen Tisch herum versammeln sich etwa 25 Entwickler und Manager, die diejenigen Teams vertreten, die die Änderungen gemacht haben, die jetzt zusammengeführt werden sollen. Sie sitzen zu zweit oder dritt zusammen und haben mindestens einen Laptop vor sich. Normalerweise tippt eine Person, während die anderen ihr dabei über die Schulter schauen.
Es gibt ein leises Summen frustrierter Unterhaltung. »Klingt, als würden Entwickler etwas mergen«, sagt Tom und setzt sich neben sie.
»Du kennst den Witz, oder? Wie lautet der Plural von ›Entwickler‹?«, fragt Maxine. »Merge-Konflikt!«
Tom lacht und öffnet seinen Laptop. »Ich könnte alle unsere Änderungen genauso gut jetzt in den Release-Branch einfließen lassen. Normalerweise mache ich es nicht sofort, wozu die Eile? Schau dich um … Es dauert in der Regel Tage, bis alle ihre Änderungen drin haben.«
Er öffnet die Versionsverwaltung, verschiebt mit der Maus ein paar Sachen, klickt hier und da und tippt etwas ein. Er sagt: »Erledigt!« und schließt seinen Rechner.
»Gewöhnlich bleibe ich nicht hier«, sagt er. »Wir haben kaum gemeinsamen Code mit dem Rest der Phoenix-Teams. Ich kann mich nicht erinnern, dass ich jemals ein Problem mit einem Merge hatte …«
Maxine nickt und denkt wieder darüber nach, wie seltsam es ist, dass der Data Hub zu Phoenix gehört.
»Glaubst du, dass es heute mit dem Merge klappt?«, fragt Maxine.
Tom lacht und zeigt auf den großen Bildschirm an der Stirnseite des Raums, der Purnas Desktop zeigt. »Vier Änderungen sind bisher gemergt. Fünf, wenn du unsere eigene mitrechnest. 387 sind noch da. Bei diesem Tempo wäre es meiner Meinung nach ein Wunder, wenn sie morgen fertig würden. Drei Tage, schätze ich. Mindestens.«
Im Laufe der nächsten Stunde, als erste Probleme beim Merging auftauchen, stoßen weitere Entwickler hinzu, um zu helfen. Als selbst der Platz zum Stehen knapp wird, richten sie einen zweiten War Room auf der gegenüberliegenden Seite des Flurs ein. Einer der Manager meckert: »Ich weiß nicht, warum wir nicht einfach zwei oder drei Konferenzräume vorreservieren. Das passiert jedes Mal.«
Maxine sieht einen Dev-Lead-Typen, der »git pull« in ein Terminalfenster seines Laptops eingibt. Er erhält sofort eine lange Fehlermeldung mit 43 Verschmelzungskonflikten. Maxine ist entsetzt. Sie fragt sich, wie lange es wohl dauern wird, dieses Chaos zu entwirren.
Als sie später hört, dass ein anderes Team vorschlägt, für alle Anwesenden den Quellcode auszudrucken, damit sie die ganzen Änderungen manuell abstimmen können, spuckt sie fast ihren Kaffee aus.
Eine Gruppe von zehn Personen drängt sich um den großen Monitor im vorderen Teil des Raums und studiert einen Code-Diff zwischen vier verschiedenen Änderungen desselben Abschnitts einer Datei.
Als Kurt ihren Gesichtsausdruck sieht, fragt er: »Was ist denn los?« Sprachlos gestikulierend, zeigt sie auf das Chaos und die ganzen Komplikationen.
»Entwickler sollten echte Geschäftsprobleme lösen, nicht – so – etwas … Das ist Wahnsinn.«
Kurt lacht bloß. »Du hast absolut recht. Alle Dev-Manager beschweren sich darüber, wie lästig das jedes Mal ist. Einige setzen sich dafür ein, dass diese Merges seltener stattfinden – statt einmal pro Monat vielleicht nur einmal pro Quartal.«
Maxine wird blass. »Du machst Witze, oder?«
»Nein«, sagt Kurt, wirklich amüsiert über Maxines Reaktion. »Wenn es wehtut, mach es einfach seltener. Das ist ihre Argumentation.«
»Nein, nein, nein«, erwidert Maxine bestürzt. »Es ist genau umgekehrt. Es ist zu umständlich, weil zu viel gleichzeitig zusammengeführt werden muss. Damit es leichter wird, muss man es öfter machen, damit die Merges klein bleiben und weniger Konflikte entstehen.«
Kurt lacht wieder. »Ja, natürlich«, sagt er schulterzuckend und deutet auf die ganze Szenerie.
Maxine lacht nicht, weil sie darin nichts Lustiges erkennen kann. Sie schaut auf ihre Uhr. Es ist fast halb fünf. Sie schaut auf Purnas Desktop. Nur 35 Änderungen sind durch, 359 weitere stehen noch aus. Sie haben gerade einmal zehn Prozent geschafft.
Bei diesem Tempo, denkt Maxine, werden sie noch einmal 40 Stunden brauchen – eine volle Woche.
Am nächsten Tag hockt Maxine zusammengesunken auf einem Stuhl in der Kantine, umgeben von Pizza. Der zweite Merge-Tag ist fast beendet. Sie starrt auf die großen Schilder, die überall hängen und ermahnen: »NUR für Merge-Teams.«
Maxine weiß nicht, was die Hinweise bringen sollen. In den vergangenen anderthalb Tagen war so ziemlich jeder Entwickler in einem der beiden War Rooms.
»Maxine, da bist du ja«, sagt Kurt und unterbricht ihre Träumerei. »Du meine Güte, aber sorry, du siehst schrecklich aus, wenn ich das sagen darf.«
Maxine schenkt Kurt nur ein verkniffenes Lächeln. Sie schafft es jetzt nicht, zu erklären, was sie gesehen hat und wie sehr sie das alles nervt.
Maxine weiß, dass Code-Merges niemandem Spaß machen, aber sie war nicht auf das vorbereitet, was sie in den letzten zwei Tagen erlebt hat.
Sie hat gesehen, wie Manager mit USB-Sticks Quelldateien von Computer zu Computer kopiert haben, weil ihre Teams nicht das gleiche Versionskontrollsystem wie alle anderen verwenden wollten.
Sie hat Menschen erlebt, die versucht haben, Merge-Konflikte zu lösen, die über 1.000 Zeilen lang waren, verteilt auf eine Vielzahl von Dateien.
Teilweise haben Kollegen vergessen, ihre Änderungen zu mergen, was erst aufgefallen ist, als Purna ihre Tabelle abgeglichen hat.
Es gab sogar einen Fall, bei dem sich zwei Teams mit einem semantischen Merge-Konflikt auseinandersetzen mussten – ein seltener Fall, der normalerweise nur in Horrorgeschichten vorkommt, die Entwickler sich gegenseitig erzählen, um sich Angst zu machen. Es ist das Ergebnis einer automatischen Zusammenführung, die zwar korrekt kompiliert wird, aber die Funktionsweise des Programms stark verändert. Das Schlimmste war, dass es fast nicht erkannt worden wäre, sie entdeckten es eher zufällig. Ehrlich gesagt, war sie sogar erstaunt, dass es überhaupt jemand mitbekommen und festgestellt hat: »Das sieht nicht ganz richtig aus.« Andernfalls wäre es in Produktion gerutscht, wo es zweifellos verheerende Folgen gehabt hätte.
Sie fragt sich immer wieder, wie viele solcher Fehler nicht erkannt wurden und jetzt in der Produktivumgebung gelandet sind – tickende Zeitbomben, die jederzeit hochgehen können, sobald der entsprechende Codepfad ausgeführt wird.
Schließlich erwidert sie Kurts Blick und antwortet sie: »Ich habe Dinge gesehen. Unaussprechliche Dinge, Kurt. Solch eine Verschwendung von Energie und überflüssige Quälerei … Kein Entwickler sollte das durchmachen müssen – das ist … das ist … Wahnsinn!« Wieder fehlen ihr die Worte.
»Ah«, sagt Kurt und sieht plötzlich besorgt aus. »Wirf die Pizza weg und komm mit zu den anderen Rebellen. Shannon hat soeben über die Ergebnisse ihrer Interaktionen mit den Phoenix-Dev-Teams berichtet, und sie hat eine großartige Idee.«
Maxine schaut auf ihre Hände und sieht, dass sie sich an einem kalten, halb aufgegessenen Stück Pizza festhält, mit Käse, der bereits vollständig zu einer weißen, fettigen Platte ausgehärtet ist. Sie kann sich nicht erinnern, etwas davon gegessen zu haben.
Sie wirft das Stück weg und begleitet Kurt, ohne ein Wort zu sagen.
Kurt führt Maxine weg von dem fortdauernden Merge-Wahnsinn in einen anderen Konferenzraum, in dem Tom, Brent, Shannon und Dwayne, um einen Tisch versammelt, auf sie warten. Alle lächeln und winken ihr zu. Shannon starrt sie einen Moment lang an, hält sich dann aber im Gegensatz zu Kurt höflich zurück und äußert sich nicht zu Maxines desolatem Aussehen.
»Maxine, ich glaube, das wird dir gefallen«, sagt Shannon. »Wir haben darüber nachgedacht, wie Änderungen am Data Hub gemergt werden. Damit sie getestet werden können, müssen wir immer warten, bis alle anderen Teams ihre Änderungen ebenfalls eingebracht haben.
Wir fragen uns, ob sich Data Hub von Phoenix entkoppeln lässt, damit wir unabhängig testen können«, fährt Shannon fort. »Falls das geht, könnten die QA-Leute unsere Änderungen sofort testen.«
Es dauert einige Augenblicke, bis Maxine versteht, was Shannon vorgeschlagen hat, denn sie ist noch immer geschockt und steht unter dem Eindruck ihrer Merge-Erlebnisse. Dann setzt plötzlich die Erkenntnis ein.
»Ja!«, ruft Maxine aus. »Ja, das ist eine großartige Idee. Wir können im Moment nicht viel für den Rest der Phoenix-Teams tun, aber das bedeutet nicht, dass wir uns auch mit ihnen gemeinsam herumquälen müssen.«
Kurt sagt: »Ich habe mit Purna und Kirsten gesprochen. Sie haben zwei Personen abgestellt, die uns dabei helfen sollen, den Data Hub zu testen und zu zertifizieren. Solange der Phoenix-Merge noch läuft, sind die beiden ganz für uns da. Ich wette, wir könnten alle unsere Änderungen testen, bevor die anderen fertig sind.«
Stirnrunzelnd sagt Maxine: »Aber wir brauchen immer noch eine Testumgebung, in der der Data Hub läuft.« Sie denkt einen Moment nach. »Ich frage mich, ob wir eine Data-Hub-Testumgebung einrichten können, die in unserem Cluster läuft. So ein Environment wäre um ein Vielfaches kleiner und einfacher als die Phoenix-Umgebungen. So könnte das QA-Team diese Umgebung nutzen anstelle der anderen immer knappen und umkämpften Environments.«
»Das Team, das für die Umgebungen verantwortlich ist, wird darüber nicht besonders glücklich sein«, sagt Kurt grinsend. »Was brauchst du?«
Sie schaut sich um. »Wenn mir Brent und Adam zwei oder drei Tage lange helfen würden, könnten wir meiner Meinung nach bis Montag zumindest eine vereinfachte Umgebung zum Laufen bringen. Ich weiß, dass Brent nur für Phoenix arbeiten darf, aber technisch gesehen ist der Data Hub immer noch Teil von Phoenix, richtig?«
Plötzlich ist Maxine wieder enthusiastisch. Die Idee, Data Hub aus dem Morast des Phoenix-Projekts zu befreien, begeistert sie.
»Das Erste Ideal«, sagt Brent mit einem Lächeln.
Am nächsten Tag arbeiten Maxine, Brent und Adam mit vollem Elan rund um die Uhr daran, eine abgespeckte Umgebung zu schaffen, in der sie den Data Hub betreiben und testen können. Es ist ein Wettrennen gegen den Phoenix-Merge.
Purna hat dem Plan zugestimmt, Kirsten ebenfalls und meinte dazu: »Wir haben die Regeln geschaffen, also können wir sie auch brechen. Insbesondere wenn wir damit diese verdammten Abhängigkeiten dauerhaft ausmerzen können. Alle Projektleiter würden vor Freude in die Luft springen.« Das hat Kurt ausgereicht, sich darauf einzulassen, ohne sich noch die Mühe zu machen, weitere Genehmigungen auf höherer Ebene einzuholen. »Ich werde später um Verzeihung bitten, wenn es nötig ist«, hatte Kurt das grinsend kommentiert.
Momentan versucht Brent, den Umgebungsbuild zu reproduzieren, der derzeit nur auf Toms Laptop funktioniert. Zeitgleich arbeitet Maxine mit Adam daran, die letzte Version des Data Hub in ihrer abgespeckten Phoenix-Umgebung zum Laufen zu bringen.
Sie freut sich, dass sie ein weiteres Stück des Rätsels lösen, das sie seit ihrer Verbannung ins Phoenix-Projekt umtreibt. Beide beobachten ein scrollendes Terminalfenster mit den Ausgaben des Data-Hub-Boots in der Hoffnung, dass sie gerade den letzten Fehler behoben haben. Sie starren immer noch auf die vorbeiströmenden Logmeldungen, als sie aufgeregte Stimmen aus dem Merge War Room hören.
Einer der Dev-Manager schreit: »Bitte alle einmal zuhören! Wir hatten in den letzten zwei Stunden auf der E-Commerce-Website zeitweise Probleme. Irgendetwas in Phoenix führt dazu, dass falsche oder unvollständige Aktionspreise angezeigt werden, wenn Benutzer sich den Einkaufswagen anschauen. Weiß jemand, was da gerade schiefläuft?«
Gutes Timing für einen Ausfall, denkt Maxine, als sie in den War Room kommt. Praktisch alle Dev-Manager sind bereits da, sodass es eigentlich ziemlich einfach sein sollte, herauszufinden, welcher Teil des Codes das Problem verursacht. Es ist wie bei einem akuten Herzinfarkt auf einem Kardiologenkongress – es sind genug qualifizierte Ärzte da!
Während sie zusieht, begrüßt Maxine die disziplinierte Problemlösung. Alle verhalten sich effizient, logisch und verzichten auf Schuldzuweisungen, während sie versuchen, das Problem auf ihren Laptops zu reproduzieren und systematisch zu durchdenken, was genau gerade schiefläuft.
Zehn Minuten später übernimmt die für Middleware zuständige Dev-Managerin das Kommando. Sie argumentiert überzeugend, dass das Problem in ihrem Bereich des Codes liegen muss. Es dauert nur eine Viertelstunde, bis ihr Team eine Lösung gefunden hat. »Es ist eine einzeilige Änderung.
Wir können den Fix einfach in den aktuellen Release-Branch schieben«, kündigt sie an. »Oh, verdammt, nein, das können wir nicht … Nur der SCM-Manager kann etwas auf diesen alten Release-Strang pushen. Wir brauchen Jared. Weiß einer, wo er ist?«
»Ich geh ihn suchen«, ruft jemand und rennt aus dem Raum.
»Wer ist Jared?«, fragt Maxine Kurt. Der reibt sich die Augen und versucht, nicht zu lachen.
Die Dev-Managerin erklärt mit müder Stimme: »Jared ist der Source-Code-Manager. Entwickler dürfen nicht auf die Produktivumgebung zugreifen. Nur bei P1-Problemen dürfen Entwickler Änderungen am Release-Branch vornehmen. Aber das hier ist nur ein P3-Problem. Also müssen wir entweder Ops bitten, es auf ein P1-Problem hochzustufen, was sowieso nicht passieren wird, oder Jared muss mir vorübergehend Zugang gewähren, damit ich unseren Fix einspielen kann.«
»Wenn Jared hier wäre, was würde er tun?«, fragt Maxine, die die Antwort eigentlich schon kennt.
Die Middleware-Managerin antwortet: »Er würde die Commit-ID unserer Korrektur nehmen, sie manuell in den Release-Branch kopieren und dann in die Produktivumgebung bringen.«
»Mehr nicht?«, fragt Maxine.
»Genau«, lautet die Antwort.
Maxine flucht schnaubend. Zu ihrer eigenen Überraschung ist sie tatsächlich wütend. Genau genommen fuchsteufelswild.
Vor ein paar Minuten hatte sie noch gedacht, dass der Zeitpunkt des Ausfalls günstig wäre. Dieser glückliche Patient. Die besten Experten für Herzkrankheiten, die das Problem korrekt diagnostizieren und eine Notfallbehandlung durchführen können, befanden sich zufällig im selben Raum.
Aber hier bei Parts Unlimited dürfen Ärzte den Patienten nicht anfassen. Es sei denn, ein P1-Ticket ist geöffnet worden. Und befindet sich ein Patient noch nicht am Rande des Todes, wie im Moment, darf offenbar nur Jared den Patienten behandeln. Zur Rettung macht Jared aber einfach nur das, was die Ärzte, die den Patienten selbst nicht anfassen dürfen, ihm sagen, denn Jared ist schließlich kein Arzt. Er ist auch kein Entwickler. Er ist wahrscheinlich nur ein Administrator, der Benutzer hinzufügt oder entfernt und sicherstellt, dass Daten gesichert werden.
»Keiner weiß, wo Jared ist. Vielleicht ist er noch beim Mittagessen«, sagt der Typ, der ihn gesucht hat.
»Oh, um Himmels willen«, murmelt Maxine vor sich hin. Es passiert schon wieder, denkt sie und erinnert sich daran, wie zerschlagen sie sich gestern in der Kantine gefühlt hat.
Alle versuchen, einen Notfallplan zu entwickeln, weil niemand Jared finden kann. 20 Minuten später taucht Randy auf und erklärt, dass man nichts tun könne, er aber immer noch daran arbeite, Jared endlich aufzutreiben.
Alle nicken und widmen sich wieder dem Merge.
»Und das soll vernünftig sein?!«, fragt Maxine und richtet sich dabei laut an alle, nicht mehr in der Lage, einfach nur zuzuschauen. »Warum dürfen Entwickler ihre eigenen Änderungen nicht in Produktion bringen? Warum brauchen wir Jared, um unsere Änderungen zu pushen? Er macht seinen Job sicher gut, darum geht es nicht, aber warum können wir das nicht einfach selbst erledigen?«
Der gesamte Raum verstummt. Alle blicken sie schockiert an. Als hätte sie gerade bei einer Hochzeit oder einer Beerdigung laut gerülpst. Schließlich sagt jemand: »Compliance.« Und eine andere Person stimmt ein: »Wegen der Sicherheit.«
Überall im Raumwerden weitere Gründe genannt. »ITIL, die IT Infrastructure Library.«
»Change-Management.«
»Payment Card Industry Data Security Standard.«
»Aufsichtsbehörden.«
Sie schaut sich um. Das sind alles fähige und verantwortungsbewusste Menschen. Und doch … »Na kommt, Leute. Diese Gründe ergeben überhaupt keinen Sinn. Ich glaube, der wahre Grund dafür, dass wir unsere Änderungen nicht selbst pushen dürfen, ist ganz einfach – man vertraut uns nicht. Und das stört euch nicht?! Wie kann Jared mehr über die Durchführung von Änderungen wissen als die Entwickler, die sie gemacht haben?«
Als Maxine sich umschaut, zählt sie nur etwa zehn Personen, die von ihrem Aha-Erlebnis irgendwie beunruhigt sind.
»Glaubt man, dass wir Änderungen absichtlich sabotieren? Dass jemand, der unsere Änderungen letztlich nur kopiert und einfügt, einen besseren Job macht als wir?« Maxine weiß, dass sie sich hier ziemlich weit aus dem Fenster lehnt, aber sie kann sich einfach nicht zurückhalten. »Wir sind fast alles Entwickler hier in diesem Raum. Stört es wirklich niemanden, dass man uns nicht zutraut, unsere eigenen Änderungen in die Produktivumgebung einzubringen?«
Ein paar Leute zucken mit den Achseln. Einige andere starren sie an, als sei sie verrückt oder hoffnungslos naiv.
Maxine weiß, dass sie keine aufwühlende St.-Crispins-Tag-Rede gehalten hat, wie sie Shakespeare im gleichnamigen Drama Heinrich V. in den Mund legt, aber sie ist verblüfft, dass kaum einer über diesen Zustand besonders verärgert zu sein scheint. Sie hat gehofft, dass jemand so etwas rufen würde wie: »Verdammt, ja, das nervt total, und wir werden das nicht länger hinnehmen!«
Aber stattdessen herrscht Stille.
Wir brauchen nicht einmal mehr Wachen. Wir sind so gern Gefangene, dass wir schon glauben, die Gitter seien nur dazu da, uns zu schützen.
Sie ist kurz davor, den Raum zu verlassen, als ein junger Mann mit einem Pferdeschwanz und einem Laptop unter dem Arm den Konferenzraum betritt, gefolgt von zwei Personen.
»Oh, nein«, rutscht es Maxine heraus. Das ist Jared?
Er ist noch jünger als der Praktikant, der ihr an ihrem ersten Tag hier geholfen hat. Sie hat nichts gegen junge Engineers. Im Gegenteil, sie setzt ihre größten Hoffnungen in die nächste Generation und tut alles, was sie kann, um ihnen zu helfen, ihre Ziele zu erreichen. Aber es fällt Maxine äußerst schwer, sich vorzustellen, dass Jared qualifizierter dafür sein soll, dieses Problem zu beheben, als alle anderen hier im Raum. Wenn Jared Änderungen bereitstellen kann, sollten wir dazu auch in der Lage sein, denkt sie.
Maxine sieht zu, wie er seinen Laptop für den Code-Push vorbereitet. Er braucht zehn Minuten, um sich erfolgreich einzuloggen, den Link zu dem Code zu erhalten, der gepusht werden soll, sich bei allen die Rückmeldung zu holen, dass es sich tatsächlich um den richtigen Code handelt … Wie in all den Filmszenen mit Programmierern, die Maxine so unglaubwürdig findet, versammelt sich eine Menge hinter Jared und wartet in atemloser Spannung, während er seine Arbeit macht. Als er schließlich sagt: »Es ist drin«, klatschen ihm die Leute auf den Rücken.
Maxine rollt frustriert mit den Augen. Sie ist froh, dass Jared seinen Job erledigt hat, aber letztlich hat er nichts anderes gemacht als etwas zu kopieren und einzufügen und auf einen Button zu klicken.
Als Maxine die Middleware-Managerin fragt, ob das Problem damit gelöst wurde, antwortet sie: »Noch nicht. Jared hat den Code zwar in den aktuellsten Release-Branch gebracht, aber jetzt muss er die Änderungen noch zusammen mit den Leuten von Ops in die Produktivumgebung bereitstellen.«
Der Patient ist noch nicht gerettet. Er muss erst noch in eine andere Abteilung transportiert werden. Sie beschließt, Jared zu folgen – eher aus einem Gefühl krankhafter Neugier denn aus Lust auf Abenteuer.
Vier Stunden, nachdem sie Jared aus dem Raum gefolgt ist, fühlt Maxine sich benommen und desorientiert. Jegliches Gefühl des Wohlbefindens und der Aufregung, das Maxine bei der Arbeit an den Data-Hub-Umgebungen empfunden hatte, ist verschwunden. Und Maxine fehlt noch etwas anderes – sie ist sich nicht mehr sicher, was gut und was schlecht ist und welche Prozesse ihre Welt regieren.
Sie fühlt sich deutlich unwohl. Bekomme ich Fieber?
Es hat damit begonnen, dass sie Jared zwei Stockwerke hinunter ins Erdgeschoss gefolgt ist, wo Operations residiert. In einem Ops-Konferenzraum erkennt sie Wes und Patty, aber fast niemanden sonst, vielleicht weil sich alle unheimlich ähnlich sahen.
Der Raum sieht fast genauso aus wie der Merge War Room im Obergeschoss. Gleiche Möbel, gleiche Lautsprecher auf dem Tisch, gleicher Beamer an der Decke. Aber um den Tisch herum sitzt eine ganz andere Gruppe von Menschen, die dennoch genau dasselbe Thema wie oben diskutiert: wie man diese wichtige Änderung bereitstellen kann. Sie diskutieren bloß über etwas andere Hindernisse: Keine Änderungen außerhalb der Wartungszeitfenster. IT Infrastructure Library. Sicherheit. Change-Management. Compliance. Unterschiedliches Ticketing-System. Gleiche Anzahl von auszufüllenden Feldern und die gleichen Fehlermeldungen, wenn eines nicht richtig ausgefüllt wird. Die gleichen Eskalationsprozesse, aber unterschiedliche Personen.
Sie haben Bill Palmer, dem VP of Operations, und Maggie Lee, Senior Director for Product Marketing, einen Emergency Change Request vorgelegt. Und genau wie oben stehen alle herum und warten auf das Okay.
Um fünf Uhr bestellt jemand eine Pizza. Maxine folgt den anderen in den Speisesaal, der genauso aussieht wie der oben. Als sie die Pizza sieht, stolpert sie fast vor Überraschung – sie stammt aus derselben Quelle wie die gestrige Pizza für das Mittagessen beim Merge-Meeting.
Die gleiche Pizza, die von verschiedenen Leuten gegessen wird, die sich über dieselben Probleme beschweren. In diesem Moment beginnt Maxine, sich wirklich krank zu fühlen, der Raum dreht sich leicht. Vielleicht habe ich einfach nur Hunger? Aber als sie noch mal einen Blick auf die Pizza wirft, dreht sich ihr sofort der Magen um.
Maxine hat das Gefühl, dieselbe Szene wie die vor gerade einmal sechs Stunden noch einmal zu erleben. Wie eine schreckliche Version von ›Und ewig grüßt das Murmeltier‹, denkt sie. Wie Bill Murray ist sie dazu verdammt, sich immer wieder in ein und demselben Tag wiederzufinden. Nur dass für Maxine die Akteure durchgewechselt werden. Zuerst sind es Entwickler, dann Leute von QA und dann von Ops. Aber letztlich ist alles das Gleiche.
Bis jetzt hegte Maxine tief in ihrem Herzen den Verdacht, dass die Entwickler von einer herzlosen, bösen, gefühllosen Bürokratie gefangen gehalten werden. Die vielleicht von Operations oder von einem ITIL-Change-Management-Geheimbund gesteuert wird. Aber nachdem sie Jared in das Herz von Operations gefolgt ist, erkennt sie, dass Ops von den gleichen Wärtern gefangen gehalten wird wie die Entwickler.
Wer profitiert von all dem? Wer hat etwas davon, alle ITler zu unterdrücken? Maxine bezweifelt, dass Chris oder Bill die Aufseher in diesen unendlich vielen Gefängnissen sind. Eher sind sie ebenfalls Gefangene.
Maxine wirft ihr Stück Pizza weg, bevor sie überhaupt einen Bissen probiert hat. Zurück im Konferenzraum, gibt Wes bekannt, dass die Notfalländerung gerade genehmigt wurde. Maggie (diejenige, die die Änderung genehmigen musste) hatte die ersten Anrufe verpasst, weil sie gerade ihren Geburtstag feierte, aber hat die Feier dann kurz verlassen, um an der Telefonkonferenz teilzunehmen.
Es dauert 40 Minuten, um die Änderung bereitzustellen. Maxine beobachtet, wie die Teams in Netzwerkfreigaben, Wiki-Seiten und Quellcode-Repositories stöbern … und dann bestätigt Patty, dass das Problem gelöst sei.
Wes bedankt sich bei allen, die so lange geblieben sind, und die Versammlung löst sich auf. Bald ist Maxine allein im Konferenzraum. Die Lichter erlöschen nach und nach, da die Bewegungssensoren keine Bewegung mehr erkennen. Im Dunkeln fragt sich Maxine, wie die Unterdrückungsbürokratie so viel Kontrolle gewinnen konnte.
Es ist genau so, wie Erik behauptet hat. Es widerspricht dem Dritten Ideal, dass wir die Arbeitsprozesse und -muster nicht verbessern, sondern ihnen blindlings folgen, denkt sie. Und nun haben uns die Abläufe und Verfahren vollständig versklavt, uns die Freude an unserer täglichen Arbeit genommen und uns damit auch immer weiter vom Zweiten Ideal entfernt.
Im Dunkeln nimmt Maxine ihr Telefon in die Hand und schreibt Kurt und dem Rest der Rebellion eine Nachricht:
Ist sonst noch jemand hier? Ich brauche wirklich ein bisschen Unterstützung.
Und einen Drink. Hat jemand Lust, sich im Dockside zu treffen?