Das große Refactoring

Shownotes

Der Zahlungsabwicklungsserver ist abgestürzt und verursacht einen Datenbankfehler. Da der einzige Entwickler, der das System versteht, vor drei Jahren zu Google gegangen ist, versammelt der IT-Leiter das gesamte Team und versucht, die Situation zu klären. Die Dokumentation ist unzureichend, da das System vor acht Jahren von einem Entwickler im Alleingang geschrieben wurde.

Transkript anzeigen

00:00:00: Das große Refactoring.

00:00:01: "Der Zahlungsabwicklungsserver ist abgestürzt."

00:00:05: verkündete Kevin ohne Umschweife, als er ohne anzuklopfen in mein Büro platzte.

00:00:10: "Keine Begrüßung. Kein Guten Morgen. Nur die nackte hässliche Wahrheit. Typisch Kevin. Ich blinzelte."

00:00:19: "Wieder? Das ist das dritte Mal in diesem Monat."

00:00:22: Ich versuchte ruhig zu klingen, aber innerlich begann ich bereits, meine Joboptionen zu überdenken.

00:00:30: "Vielleicht war es Zeit, Schafhörte in Island zu werden."

00:00:33: Kevin nickte grimmig.

00:00:35: "Und diesmal ist er nicht einfach wieder hochgefahren. Wir haben einen kompletten Datenbankfehler."

00:00:40: Er sagte es mit der Beiläufigkeit eines Mannes, der gerade mitteilt, dass das Bürogebäude in Flammen steht. Aber hey! Keine große Sache.

00:00:49: Ich spürte, wie sich ein dumpfes Pochen in meinen Schläfen ausbreitete.

00:00:54: Der Vorbot einer Migräne oder einer besonders unangenehmen IT-Krise.

00:01:00: In diesem Fall wahrscheinlich beides.

00:01:02: "Wie schlimm ist es?" fragte ich. Obwohl ich die Antwort bereits ahnte.

00:01:07: "Auf einer Scala von eins bis zehn? Etwa eine fünfzehn, antwortete Kevin.

00:01:13: Die Transaktionen der letzten zwei Stunden sind in einem undefinierten Zustand.

00:01:18: Wir wissen nicht, welche durchgegangen sind und welche nicht."

00:01:22: Ich schloss kurz die Augen und zählte innerlich bis zehn.

00:01:28: Als IT-Leiter lernt man schnell, dass Panik selten hilft, auch wenn sie oft die natürlichste Reaktion wäre.

00:01:35: "Okay," sagte ich schließlich.

00:01:37: "Ruf das Team zusammen, Konferenzraum in zehn Minuten und bring den Entwickler mit, der am meisten über das Zahlungssystem weiß."

00:01:46: Ich klang ruhig und kontrolliert wie ein Kapitän, der sein sinkendes Schiff kommandiert.

00:01:52: Innerlich schrie ich wie ein kleines Mädchen.

00:01:55: Kevin zögerte.

00:01:57: "Das ist das Problem. Der einzige, der das System wirklich versteht, ist Michael und der ist vor drei Jahren zu Google gegangen."

00:02:05: Natürlich. Warum sollte es auch einfach sein?

00:02:09: Das Leben eines IT-Leiters ist nie einfach.

00:02:13: Es ist, als würde das Universum ständig neue, kreative Wege finden, um dir zu zeigen, dass du eigentlich keine Ahnung hast, was du tust.

00:02:23: "Dann bring mir alle, die jemals daran gearbeitet haben. Und die Dokumentation."

00:02:27: Ich versuchte zuversichtlich zu klingen, als ob es tatsächlich eine Dokumentation gäbe, die mehr wäre als ein paar verstreute Kommentare im Code und eine halbfertige README-Datei von 2015.

00:02:42: Kevin lachte trocken.

00:02:44: "Welche Dokumentation?"

00:02:46: Es war das Lachen eines Mannes, der weiß, dass wir beide eine Lüge leben.

00:02:51: Die Lüge, dass Software-Entwicklung ein organisierter dokumentierter Prozess ist und nicht ein chaotisches Durcheinander aus Hacks, Workarounds und gelegentlichen Momenten brillanter Verzweiflung.

00:03:03: Zehn Minuten später saß ich in einem Konferenzraum voller nervöser Entwickler, die aussahen, als hätte man sie zu einer spontanen Wurzelbehandlung ohne Betäubung eingeladen.

00:03:16: Sarah tippte hektisch auf ihrem Laptop, Markus starte mit leerem Blick auf sein Smartphone, wahrscheinlich auf der Suche nach Job angeboten.

00:03:25: Mira hatte bereits eine improvisierte Kommandozentrale mit drei Bildschirmen aufgebaut und murmelte leise Flüche, während sie durch Lock-Dateien scrollte.

00:03:36: "Also?" begann ich.

00:03:38: "Was wissen wir über das Zahlungssystem?"

00:03:41: Ich versuchte es klingen zu lassen, als wäre dies eine normale alltägliche Frage und nicht der verzweifelte Hilferuf eines Mannes, der gerade realisiert hat, dass er für ein System verantwortlich ist, das er nicht versteht.

00:03:55: Die Antwort war ernüchternd, nicht viel.

00:03:58: Das System war vor fast acht Jahren entwickelt worden, in einer Zeit, als unsere Firma noch ein Start-up war und schnell und schmutzig, das in offizielle Entwicklungsmotto.

00:04:10: Der ursprüngliche Entwickler, besagter Michael, hatte das System praktisch im Alleingang geschrieben, mit minimaler Dokumentation und einem Code-Steal, den man wohlwollend als kreativ bezeichnen könnte.

00:04:23: Im Laufe der Jahre hatten verschiedene Entwickler Patches und Erweiterungen hinzugefügt, jeder mit seinem eigenen Stil und seinen eigenen Vorstellungen davon, wie das System funktionieren sollte.

00:04:38: Das Ergebnis war ein digitaler Frankenstein, zusammengeflickt aus verschiedenen Technologien, Programmierparadigmen und gelegentlichen Verzweiflungslösungen.

00:04:48: "Wir haben es immer wieder gepatched und erweitert, aber nie grundlegend überarbeitet", erklärte Sarah.

00:04:55: "Es ist wie ein Haus, bei dem man immer wieder Anbauten hinzufügt, ohne jemals das Fundament zu verstärken."

00:05:03: "Und jetzt ist das Fundament eingestürzt?" ergänzte Kevin Düster. Er hatte dieses spezielle Talent, schlechte Nachrichten noch schlimmer klingen zu lassen, als sie ohnehin schon waren. Ich nickte langsam.

00:05:16: "Okay. Erste Priorität. Wir müssen das System wieder zum Laufen bringen. Wie lange wird das dauern?"

00:05:24: Ich stellte die Frage mit der gleichen Mischung aus Hoffnung und Furcht, mit der man einen Arzt fragt, wie lange man noch zu leben hat.

00:05:32: Die Blicke, die ausgetauscht wurden, waren nicht ermutigend. Es waren die Blicke von Menschen, die wissen, dass sie eine schlechte Nachricht überbringen müssen, aber keiner will derjenige sein, der es tut.

00:05:45: "Mit viel Glück und noch mehr Kaffee? Vielleicht bis heute Abend?" sagte Mira schließlich. "Aber es wird ein Flickwerk sein. Keine dauerhafte Lösung."

00:05:56: "Und ohne Glück?" fragte ich, obwohl ich die Antwort fürchtete. "Dann sitzen wir hier noch am Wochenende?" antwortete sie ehrlich.

00:06:06: Sie sagte nicht und möglicherweise auch nächste Woche. Aber ich konnte es in ihren Augen lesen. Ich atmete tief durch.

00:06:14: "Okay. Ihr kümmert euch um die Notfallreparatur. Ich informiere das Management und bereite sie darauf vor, dass wir möglicherweise ein größeres Problem haben als nur ein vorübergehenden Ausfall."

00:06:28: Die nächsten Stunden verschwammen zu einem Wirbel aus Krisengesprächen, technischen Diskussionen und zunehmender Frustration.

00:06:36: Das Team arbeitete fieberhaft daran, das System zu flicken, während ich zwischen Management-Meetings und technischen Updates hin und her pendelte, wie ein Ping-Pong-Ball in einem besonders aggressiven Match.

00:06:50: Gegen Abend kam endlich die erlösende Nachricht. Das System lief wieder. Die Transaktionen der letzten Stunden waren größtenteils rekonstruiert worden, mit nur minimalen Datenverlusten.

00:07:01: Die Krise war vorerst abgewendet. Es war, als hätte man einen Herzinfarkt überlebt. Er leichtert, aber mit dem Wissen, dass das grundlegende Problem noch immer besteht.

00:07:14: Aber als ich in die erschöpften Gesichter meines Teams blickte, wusste ich, dass dies nur der Anfang war.

00:07:20: Das grundlegende Problem, unser chaotischer veralteter Legacy Code, war noch immer da, eine tickende Zeitbombe, die jederzeit wieder explodieren konnte.

00:07:31: "Wir müssen darüber reden", sagte ich, als wir uns am nächsten Morgen zu einer Nachbesprechung trafen.

00:07:37: "Über das Zahlungssystem, über all unseren Legacy Code."

00:07:42: Ich klang wie ein Vater, der seinen Kindern erklären muss, dass der Hund nicht auf eine Farm gegangen ist, sondern tatsächlich gestorben ist.

00:07:51: Die Reaktionen waren gemischt. Einige nickten zustimmend, andere schauten skeptisch.

00:07:58: "Was schwebt ihr vor?" fragte Sarah. Sie klang vorsichtig optimistisch.

00:08:05: "Ein komplettes Refactoring", antwortete ich. "Nicht nur Patches und Erweiterungen, eine grundlegende Überarbeitung des gesamten Systems."

00:08:14: Ich sagte es mit der Entschlossenheit eines Mannes, der gerade beschlossen hat, sein Haus abzureißen und neu zu bauen, anstatt weiterhin undichte Stellen zu flicken.

00:08:25: Kevin Pfiff leise durch die Zähne.

00:08:28: "Das ist ein riesiges Unterfangen. Wir reden hier von monaten Arbeit." Er klang beeindruckt und entsetzt zugleich.

00:08:36: "Ich weiß." Zwingendes sagte ich.

00:08:38: "Aber die Alternative ist, weiterhin Feuer zu löschen. Bis eines Tages ein Brand ausbricht, den wir nicht mehr unter Kontrolle bekommen."

00:08:47: Ich versuchte entschlossen zu klingen, nicht wie jemand, der insgeheim hofft, dass er bis dahin längst in einer anderen Firma arbeitet.

00:08:57: Die Diskussion, die folgte, war lang und intensiv. Wir sprachen über technische Schulden, jene unsichtbaren Kosten, die entstehen, wenn man kurzfristige Lösungen langfristigen Qualitätsstandards vorzieht.

00:09:10: Wir sprachen über die Risiken eines großen Refactorings gegenüber dem Risiko, nichts zu tun.

00:09:17: Wir sprachen über Ressourcen, Zeitpläne und die unvermeidliche Frage. Wie überzeugen wir das Management in etwas zu investieren, das von außen betrachtet keinen unmittelbaren Mehrwert bringt?

00:09:31: Am Ende einigten wir uns auf einen Plan. Wir würden ein umfassendes Refactoring des Zahlungssystems vorschlagen, mit klaren Meilenstein, messbaren Verbesserungen und einer detaillierten Risiko-Bewertung.

00:09:44: Und ich würde die undankbare Aufgabe übernehmen, das Management davon zu überzeugen. Die Präsentation vor dem Vorstand eine Woche später war.

00:09:55: Nun, herausfordernd wäre eine höfliche Umschreibung. Ich stand vor einer Gruppe von Menschen, deren Verständnis von Technologie von oberflächlich bis praktisch nicht vorhanden reichte und versuchte ihnen zu erklären, warum wir mehrere Monate und erhebliche Ressourcen in etwas investieren sollten, dass, wenn alles gut ging, genauso funktionieren würde wie vorher.

00:10:20: Lassen Sie mich das richtig verstehen, sagte Herr Brinkmann, unser Finanzvorstand mit gerunzelter Stirn.

00:10:27: Sie wollen, dass wir Geld ausgeben, um etwas zu reparieren, das nicht kaputt ist?

00:10:32: Er sah mich an, als hätte ich vorgeschlagen, das Firmengebäude Gold zu streichen, weil es hübscher aussieht.

00:10:40: Es ist kaputt, erwiderte ich.

00:10:43: Es ist nur noch nicht vollständig zusammengebrochen. Wie ein Auto mit abgefahrenen Bremsen. Es fährt noch. Aber wenn sie nicht bald die Bremsen erneuern, werden sie eines Tages nicht mehr anhalten können.

00:10:54: Ich versuchte ruhig und sachlich zu bleiben, obwohl ich innerlich schrie.

00:11:00: Ja, verdammt, es ist kaputt. Es ist so kaputt, wie meine Hoffnung auf eine vernünftige Diskussion mit ihnen.

00:11:06: Aber wir hatten doch gerade erst einen Ausfall und ihr Team hat ihn behoben.

00:11:11: Argumentierte Frau Lehmann, die Vertriebsvorständin.

00:11:15: Warum können wir nicht einfach so weitermachen? Probleme beheben, wenn sie auftreten?

00:11:20: Ich unterdrückte den Impuls, meinen Kopf gegen die Wand zu schlagen.

00:11:24: Stattdessen versuchte ich es mit einer anderen Analogie, einer, die selbst der technisch unbedarfteste Manager verstehen würde.

00:11:33: Stellen Sie sich vor, Sie haben ein altes Haus mit veralteter Elektrik.

00:11:38: Sie können weiterhin Sicherungen austauschen, wenn Sie durchbrennen oder Löcher in den Wänden flicken, wenn Kabel anfangen zu schmoren.

00:11:46: Aber irgendwann wird das Haus abbrennen.

00:11:49: Was wir vorschlagen, ist ein

00:12:07: eine vollständige Erneuerung der Elektrik, bevor es zu spät ist.

00:11:55: Ich schaute sie eindringlich an, in der Hoffnung, dass das Bild eines brennenden Hauses und damit

00:12:02: brennender Firmgewinne sie überzeugen würde. Diese Analogie schien besser anzukommen. Nach

00:12:08: weiteren zwei Stunden Diskussion, unzähligen Fragen und einigen überraschend leidenschaftlichen

00:12:14: Plädoyés von unserem CTO. Der Gott sei Dank tatsächlich verstand, worum es ging, erhielten

00:12:21: wir schließlich die Genehmigung für das Refactoring-Projekt. Mit einem Vorbehalt. Wir hatten drei

00:12:27: Monate Zeit, nicht die sechs, die wir ursprünglich veranschlagt hatten.

00:12:31: Drei Monate sind besser als nichts, sagte ich zu meinem Team, als wir uns zur Projektplanung

00:12:37: trafen, aber es wird eng werden. Ich versuchte, optimistisch zu klingen, nicht wie jemand,

00:12:43: der gerade realisiert hat, dass er sich freiwillig für eine Mission gemeldet hat, die wahrscheinlich

00:12:48: in einer Katastrophe enden wird. Eng ist eine Untertreibung, murmelte Kevin. Es wird ein

00:12:55: Höllentrip werden. Und so begann das, was später als das große Refactoring in die Geschichte

00:13:02: unserer Firma eingehen sollte. Drei Monate intensive Arbeit, in denen wir praktisch im

00:13:08: Büro lebten, mehr Kaffee konsumierten als medizinisch vertretbar und Code umschrieben,

00:13:14: der älter war als einige unserer Praktikanten. Die ersten Wochen waren die schwierigsten.

00:13:20: Wir mussten den bestehenden Code verstehen, bevor wir ihn überarbeiten konnten. Eine

00:13:25: Aufgabe, die sich als ähnlich komplex erwies, wieder Versuch, eine alte, vergilbte Landkarte

00:13:31: in einer fremden Sprache zu entziffern. Es gab Funktionen, deren Zweck niemand kannte,

00:13:36: Variablen mit kryptischen Namen und Kommentare, die mehr Fragen aufwarfen, als sie beantworteten.

00:13:43: "Wer zum Teufel schreibt so etwas?" fragte Markus eines Tages, während er auf ein besonders

00:13:49: verwirrenden Code-Abschnitt starte. "Es ist, als hätte jemand absichtlich versucht, es

00:13:56: unverständlich zu machen." "Wahrscheinlich jemand, der nicht wollte, dass er ersetzt

00:14:01: wird," antwortete Sarah Trocken. "Job Sicherheit durch Unverständlichkeit."

00:14:05: Langsam aber sicher begannen wir, den Code zu entschlüsseln und zu überarbeiten. Wir

00:14:12: führten moderne Entwicklungspraktiken ein, schrieben Tests, verbesserten die Dokumentation

00:14:18: und refactorten den Code in kleinere verständlichere Module. Es war wie die Renovierung eines

00:14:24: alten Hauses. Man weiß nie, was man findet, wenn man die Wände aufreißt, aber am Ende

00:14:30: ist es die Mühe wert. Es gab Rückschläge, natürlich, Funktionen, die plötzlich nicht

00:14:35: mehr funktionierten, Tests, die unerklärliche Fehler aufwiesen und die gelegentliche Entdeckung

00:14:42: von Code, der so bizarr war, dass wir uns fragten, ob er von einem Menschen oder einem

00:14:47: besonders verwirrten Algorithmus geschrieben worden war. "Ich glaube, ich habe gerade Code

00:14:53: gefunden, der nur funktioniert, wenn es Dienstag ist," verkündete Mira eines Nachmittags,

00:15:00: mit einer Mischung aus Entsetzen und wiederwilliger Bewunderung. "Buchstäblich. Es gibt eine

00:15:06: Abfrage des Wochentags und wenn es Dienstag ist, wird ein völlig anderer Code-Pfad ausgeführt."

00:15:13: "Warum?" fragte ich, obwohl ich die Antwort fürchtete. "Keine Ahnung," antwortete sie,

00:15:21: "es gibt kein Kommentar, keine Erklärung, nur Code, der am Dienstag anders funktioniert

00:15:27: als an allen anderen Tagen." Wir nannten es den Dienstagsbug und fügten

00:15:33: ihn zu unserer wachsenden Liste von "Ding, die keinen Sinn ergeben", aber irgendwie

00:15:38: funktionieren hinzu. Eine Liste, die beunruhigend lang wurde. Trotz aller Herausforderungen

00:15:45: machten wir Fortschritte. Langsam, aber stetig. Wie eine Gruppe von Archäologen, die eine

00:15:53: antike Stadt ausgraben, legten wir Schicht für Schicht des alten Codes frei. Verstanden

00:15:58: seine Struktur und bauten ihn neu auf, besser, stärker, verständlicher. Und dann, zwei Wochen

00:16:05: vor unserer Deadline kam der Moment der Wahrheit, der erste vollständige Test des neuen Systems.

00:16:12: Wir hatten es in einer isolierten Umgebung entwickelt, mit simulierten Daten und kontrollierten

00:16:18: Bedingungen. Jetzt war es Zeit, es mit echten Daten zu testen, in einer Umgebung, die der

00:16:24: Produktion so nahe wie möglich kam. Wir versammelten uns alle im Konferenzraum, starten auf den

00:16:30: großen Bildschirmen der Wand und hielten kollektiv den Atem an, als Mira den Staatbefehl

00:16:36: gab. Es war wieder Countdown zu einem Raketenstart, nur dass wir alle wussten, dass die Rakete

00:16:42: genauso gut explodieren, wie abheben könnte. Die ersten Minuten waren vielversprechend.

00:16:48: Das System startete, die Datenbank wurde initialisiert, die ersten Transaktionen wurden verarbeitet,

00:16:55: wir begannen vorsichtig zu hoffen. Vielleicht, nur vielleicht, würde es tatsächlich funktionieren.

00:17:03: Und dann, nach etwa 20 Minuten, begann alles zusammenzubrechen. Fehler tauchten auf, Transaktionen

00:17:11: schlugen fehl. Die Datenbank geriet in einen inkonsistenten Zustand. Es war, als würde

00:17:18: man zusehen, wie ein Kartenhaus langsam in sich zusammenfällt. Die Stimmung im Raum

00:17:23: sang von vorsichtigem Optimismus zu tiefer Verzweiflung. Drei Monate harte Arbeit und

00:17:30: wir waren wieder am Anfang. Oder schlimmer noch, wir hatten ein System, das noch weniger

00:17:36: funktionierte als das Alte. "Was ist passiert?" fragte ich, als der Bildschirm schließlich

00:17:42: nur noch eine endlose Liste von Fehlermeldungen zeigte. Mira schüttelte den Kopf. "Ich bin

00:17:48: nicht sicher. Es könnte ein Problem mit der Datenbankstruktur sein oder mit der Art, wie

00:17:54: wir die Transaktionen verarbeiten, oder..." "Sie brach ab, offensichtlich überwältigt

00:18:00: von den Möglichkeiten." "Oder es könnte der Dienstagsbuch sein," ergänzte Kevin

00:18:05: Düster. "Heute ist Dienstag." "Wir starten uns an. Plötzlich von der absurden Möglichkeit

00:18:12: getroffen, dass er recht haben könnte, dass unser gesamtes System tatsächlich von einem

00:18:18: mysteriösen Buch abhängen könnte, der nur an Dienstagen auftritt." "Das ist lächerlich,"

00:18:24: sagte ich schließlich. "Wir können nicht ernsthaft ein System haben, das nur an bestimmten

00:18:29: Wochentagen funktioniert." "Aber selbst während ich es sagte, wusste ich, dass es durchaus

00:18:36: möglich war. In der IT-Welt sind die absurdesten Erklärungen oft die richtigen." "Lasst uns

00:18:43: den Test morgen wiederholen," schlug Sarah vor. "Wenn es am Mittwoch funktioniert, wissen

00:18:48: wir, dass es der Dienstagsbuch ist." "Und so verbrachten wir die nächsten 24 Stunden

00:18:53: in einem Zustand nervöser Erwartungen, wie Eltern, die auf die Ergebnisse eines medizinischen

00:18:59: Tests warten. Als der Mittwoch endlich kam, wiederholten wir den Test und zu unserer

00:19:06: Überraschung und Erleichterung funktioniert alles perfekt. Keine Fehler, keine Abstürze,

00:19:12: keine mysteriösen Inkonsistenzen." "Es ist tatsächlich der Dienstagsbuch," sagte

00:19:18: Mira unglaublich. "Unser System funktioniert an jedem Tag außer Dienstag." "Wir verbrachten

00:19:25: die nächsten Tage damit, den Dienstagsbuch zu jagen und zu eliminieren. Eine Aufgabe,

00:19:31: die sich als überraschend komplex erwies. Es stellte sich heraus, dass der ursprüngliche

00:19:37: Entwickler eine spezielle Behandlung für Dienstage eingebaut hatte, weil an diesem Tag regelmäßig

00:19:43: Wartungsarbeiten an einem externen System durchgeführt wurden, mit dem unser System kommunizierte.

00:19:50: Eine Information, die natürlich nirgendwo dokumentiert war, als wir schließlich den

00:19:56: Bug behoben hatten und das System an allen sieben Tagen der Woche gleich funktionierte,

00:20:01: fühlten wir uns wie Helden. Wir hatten das Unmögliche geschafft, ein Legacy-System vollständig

00:20:08: refactored, ohne seine Funktionalität zu beeinträchtigen, außer vielleicht für die

00:20:13: jenigen, die sich auf das seltsame Dienstagsverhalten verlassen hatten. Die letzten Tage vor der

00:20:20: Deadline waren ein Wirbel aus Tests, Fehlerbehebungen und letzten Optimierungen. Wir arbeiteten

00:20:26: bis spät in die Nacht, lebten von Kaffee und Fertiggerichten und Träumten in Code-Zeilen.

00:20:32: Aber wir schafften es. Drei Monate nach Beginn des Projekts, genau am Tag der Deadline, rollten

00:20:38: wir das neue System aus. Der Rollout selbst war überraschend unspektakulär. Keine dramatischen

00:20:45: Fehler, keine Systemabstürze, keine verzweifelten Notfallmaßnahmen. Das neue System lief einfach,

00:20:52: still und effizient, wie ein gut geöltes Uhrwerk. Es war fast enttäuschend nach all der Dramatik

00:20:59: der vergangenen Monate. "Ist das alles?" fragte Kevin, als wir im Konferenzraum saßen

00:21:05: und auf die Monitore starten, die alle grün leuchteten. "Kein Feuer, keine Explosionen,

00:21:12: keine verzweifelten Anrufe von wütenden Kunden?" "Sei froh!" erwiderte ich. "In unserem Job

00:21:19: ist langeweile ein Zeichen für Erfolg." In den folgenden Wochen zeigte sich, dass unser

00:21:25: Refactoring tatsächlich ein Erfolg war. Das System lief stabiler als je zuvor, war einfacher

00:21:31: zu warten und zu erweitern. Und, was vielleicht am wichtigsten war, wir verstanden es jetzt.

00:21:39: Es war nicht mehr der mysteriöse Schwarze Kasten, den niemand zu berühren wagte, sondern

00:21:44: ein transparentes, gut dokumentiertes System, mit dem wir arbeiten konnten. Das Management

00:21:51: war zufrieden, wenn auch auf eine etwas verwirrte Art. Sie hatten eine erhebliche Summe Geld

00:21:57: ausgegeben, um etwas zu bekommen, das für sie genau so aussah wie vorher. Es war, als

00:22:03: hätte man sein Auto zur Reparatur gebracht und es in exakt demselben Zustand zurückbekommen.

00:22:09: Nur, dass der Mechaniker weiß, dass er den Motor komplett ausgetauscht hat.

00:22:14: "War es das Wert?" fragte mich der CEO eines Tages, als wir uns zufällig in der Kantine

00:22:20: trafen. "All die Zeit und das Geld für etwas, das für den Endbenutzer keinen Unterschied

00:22:25: macht." "Ich dachte einen Moment nach."

00:22:29: "Stellen Sie sich vor, Sie leben in einem Haus mit einer tickenden Zeitbombe im Keller,"

00:22:34: sagte ich schließlich. "Sie wissen nicht genau, wann sie explodieren wird, aber Sie

00:22:39: wissen, dass es irgendwann passieren wird. Jetzt haben wir die Bombe entschärft. Sie

00:22:44: sehen keinen Unterschied, weil das Haus immer noch gleich aussieht. Aber Sie können jetzt

00:22:49: ruhig schlafen." Er nickte langsam. "Ich verstehe, manchmal

00:22:54: ist die wichtigste Arbeit die, die man nicht sieht."

00:22:56: "Genau," stimmte ich zu. "Und manchmal ist die beste Katastrophe die, die nie eintritt."

00:23:03: Als ich später darüber nachdachte, wurde mir klar, dass dies vielleicht die perfekte

00:23:08: Metapher für die Arbeit in der IT ist. Wir verbringen einen Großteil unserer Zeit, damit

00:23:14: unsichtbare Probleme zu lösen, potenzielle Katastrophen abzuwenden und Systeme am Laufen

00:23:21: zu halten, die die meisten Menschen für selbstverständlich halten. Es ist nicht glamourös, es wird selten

00:23:28: anerkannt, aber es ist notwendig. Und manchmal, nur manchmal, wenn wir unseren Job richtig

00:23:34: machen, merkt niemand, dass wir überhaupt etwas getan haben. Und das ist vielleicht der größte

00:23:40: Erfolg von allen.

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.