Projekt Unicorn. Gene Kim
ist sie traurig und entmutigt – in ihrer Arbeit findet sie nichts von der Freude am Lernen, die sie hier gerade erlebt hat. Sie fragt sich, ob sich wohl alle am Phoenix-Projekt Beteiligten immer so fühlen wie sie jetzt.
Maxine will gerade ihr Auto starten, als ihr Telefon vibriert. Es ist eine Textnachricht von einem ihrer Kollegen bei einem Open-Source-Projekt für eine persönliche Aufgabenverwaltung, das sie geschrieben hat. Sie hat dieses Projekt vor über fünf Jahren begonnen, um endlich richtig gute Arbeitstagebücher führen zu können. Sie hat schon immer wie besessen Protokoll darüber geführt, womit sie ihre Zeit verbringt.
Anfangs war es nur dazu gedacht, ihr dabei zu helfen, produktiver zu werden und die eingehenden Aufgaben aus E-Mails, Trello, Slack, Twitter, Leselisten und einer Fantastilliarde anderer Quellen, aus denen Arbeit strömt, vorzusortieren. Mit ihrer Anwendung kann sie Aufgaben leicht zu GitHub, JIRA, Trello und in die vielen anderen Tools weiterleiten, über die sie mit anderen Menschen und Teams interagiert.
Seit Jahren setzt sie dieses Programm täglich ein, um einen großen Teil ihres beruflichen und privaten Lebens zu organisieren. Sie verwaltet alle ihre Aufgaben darin. Es ist ihre Master-Inbox, in der sie ihre gesamten Tasks sehen und die Arbeit zwischen den verschiedenen Systemen verschieben kann, mit denen sie arbeitet.
Viele andere Menschen nutzen ebenfalls diese Anwendung, und einige Nutzer wiederum haben Schnittstellen zu anderen Tools geschrieben, die sie einsetzen. Sie wundert sich immer wieder darüber, dass täglich Tausende von Menschen auf der ganzen Welt ihre Anwendung benutzen und mehr als 20 Personen aktiv am Code mitwirken.
Sie schaut sich die Nachricht mit dem neuen Pull-Request an – jemand hat für den Task-Manager eine weitere Schnittstelle geschrieben. Die vorgeschlagene Änderung sieht fantastisch aus. Etwas, das sie schon seit Jahren einbauen wollte. Die Änderung ist ziemlich clever, und sie stimmt der Art und Weise zu, wie die automatisierten Tests geschrieben wurden, die beweisen, dass die Änderung keine negativen Auswirkungen hat. Der Vorschlag ist gut dokumentiert und nachvollziehbar erklärt. Sie begrüßt, dass der kurze Text als eine Art Tutorial formuliert wurde, sodass andere etwas Ähnliches umsetzen können.
Sie freut sich über den Einfallsreichtum anderer Menschen und deren Bereitschaft, die Anwendung weiter zu verbessern. Als Ownerin des Projekts sieht sie es als ihre Hauptverantwortung an, dafür zu sorgen, dass alle Mitwirkenden produktiv daran arbeiten können.
Vor ein paar Jahren gab es über 20 aktive Pull-Requests, aber aus unterschiedlichsten Gründen konnte sie sie nicht zusammenführen – manchmal widersprachen sich die Änderungen, manchmal konnte die API nicht ganz das leisten, was benötigt wurde. Sie weiß, wie entmutigend es sein kann, wenn man eine Änderung für ein Projekt einreicht und niemand den Vorschlag anschaut oder man gesagt bekommt, dass er nicht integriert werden kann. Wenn das zu häufig geschieht, geben die Leute schließlich auf oder forken das Projekt und spalten die Community.
Als das auch ihrem Projekt drohte, verbrachte sie wochenlang jeden Abend damit, ihre Systemarchitektur so zu überarbeiten, dass alle Mitwirkenden die gewünschten Änderungen schnell, einfach und sicher vornehmen konnten. Das war mühsam, und sie hat persönlich jeden Pull-Request umgeschrieben, damit die Mitstreiter ihre Arbeit nicht wiederholen mussten. Aber alle waren froh und dankbar, als ihre Änderungsvorschläge es ins Projekt schafften – aber nicht annähernd so froh wie Maxine.
Maxine ist sich darüber im Klaren, dass es Agilität nicht umsonst gibt. Ohne diese Art von Aufwand wird es mit der Zeit immer schwieriger, Software zu ändern. Es gibt Ausnahmen, z. B. Bibliotheken für Fließkommaberechnungen, die sich seit 40 Jahren nicht geändert haben – die sich aber auch nicht zu ändern brauchen, weil sich die Mathematik selbst ja nicht ändert.
Aber in fast allen anderen Bereichen, insbesondere wenn man mit Kunden zu tun hat, ist Wandel eine Konstante des Lebens. Ein »gesundes« Softwaresystem ist ein System, das man mit der erforderlichen Geschwindigkeit ändern kann und bei dem andere Personen leicht Beiträge einbringen können, ohne sich übermäßig verrenken zu müssen. So kreiert man Projekte, die Spaß machen und bei denen es sich lohnt, mitzuarbeiten – und bei denen man oft die lebendigsten Communitys findet.
Sie fährt nach Hause und freut sich, dass ihr Mann sich bereits um das Abendessen gekümmert hat. Sie berichtet ihren Kindern von ihrer spontanen Entscheidung, ihre alte Schule zu besuchen, und von der jüngsten Geek-Generation.
Als sich ihre Sprösslinge verkriechen, um ihre Hausaufgaben zu machen, schnappt sie sich ihren Laptop und ruft erneut den jüngsten Pull-Request auf. Sie zieht sich den neuen Code, loggt sich ein und klickt etwas herum, um einige Grenzfälle zu testen und sicherzustellen, dass der Kollege die Details im Griff hat.
Mit einem zufriedenen Lächeln ruft sie den Pull-Request in ihrem Browser auf und klickt auf eine Schaltfläche, um den Request in die Codebasis zu mergen. Sie schreibt dem Einreicher ein kurzes Dankeschön und beglückwünscht ihn zu seiner cleveren Idee und Initiative.
Als sie gerade auf Senden klicken will, bemerkt sie noch etwas, das der Kollege geschrieben hat: »Maxine, ich würde eine Riesenparty schmeißen, falls immer dann eine Desktopbenachrichtigung angezeigt werden könnte, wenn jemand diese Eigenschaft ändert …«
Gute Idee, findet sie. Sie öffnet ihren Codeeditor und versucht in den nächsten 15 Minuten, den Vorschlag umzusetzen. Als es gleich beim ersten Mal funktioniert, lacht sie laut und applaudiert sich mit fröhlichem Selbstlob selbst. Sie ist in bester Stimmung. Dank all dieser Wunder der Technologie kann man mit wenig Aufwand wirklich viel erreichen.
Sie setzt ihre Nachricht an den Einreicher fort:
Nochmals, wirklich gute Arbeit. Ich bin sicher, dass es allen so gut gefallen wird wie mir. Danke! (Und ich habe gerade die Benachrichtigungsfunktion hinzugefügt. Dein Angebot, eine Party für mich zu schmeißen, nehme ich gerne an.)
Als sie auf Senden klickt, fragt sie sich, ob das Universum ihr eine Nachricht schicken will. Zuerst ihr Nachmittag mit den Schülern und dann die Leichtigkeit, mit der sie ihrer Anwendung (die um Jahre älter ist als das Phoenix-Projekt) gerade ein neues Feature hinzugefügt hat, haben ihr wieder gezeigt, wie sich Programmieren anfühlen sollte.
Sie kann voller Konzentration mit Flow und Freude Dinge umsetzen. Sie hat schnelles Feedback zu ihrer Arbeit bekommen. Andere Menschen konnten etwas beisteuern, ohne von einer Vielzahl weiterer Personen abhängig zu sein. Das ist es, was eine gute Architektur ermöglicht. Sie wurde in das strategisch wichtigste Projekt des Unternehmens verbannt, von dem das Überleben der ganzen Firma abhängt. Und dennoch sind Hunderte von Entwicklern wie gelähmt und nicht in der Lage zu tun, was getan werden muss.
In diesem Moment beschließt Maxine, dass sie diesen Grad an Produktivität, den sie für die Schüler und ihr Open-Source-Projekt ermöglicht hat, auch ins Phoenix-Projekt bringen muss, selbst wenn das für sie kurzfristig persönliche Opfer bedeutet.
KAPITEL 4
Donnerstag, 11. September
Am nächsten Morgen fühlt sich Maxine nach den zahlreichen gestrigen Erfolgen immer noch siegestrunken. Aber wie Kurt vorhergesagt hat, drehen alle am Rad. Bei allen herrschen Schock und Fassungslosigkeit, weil der Launch weder abgesagt noch verschoben wird. Stattdessen soll das Phoenix-Projekt morgen um fünf Uhr nachmittags freigeschaltet werden.
Als ob Captain Kirk auf Warp-Geschwindigkeit gehen will, obwohl Scotty ihm klarmacht, dass dann die Dilithiumkristalle in die Luft fliegen. Heute also keine langweiligen Statusbesprechungen. Stattdessen fühlt sich jedes Meeting wie ein waschechter Shitstorm an – mit Menschen am Rande der Panik. Ein Treffen entwickelte sich schnell zu einem chaotischen Tumult voller Fragen, Einwänden und Äußerungen schockierter Ungläubigkeit. Alle tippten wütend auf ihren Smartphones und Laptops, und ein Drittel der Teilnehmer im Raum telefonierte. Es war wie in einem alten Film aus den 1940er-Jahren, in dem die Reporter aus dem Gerichtssaal zu den Münztelefonen oder zurück in ihre Büros rennen und verzweifelt versuchen, die letzten Neuigkeiten als erste zu verkünden.
Maxine dreht sich zu ihrem Nachbarn und ruft laut: »Wurde Phoenix bisher