- 2016 entwickelte die Business-Intelligence-Organisation von Uber ein Tool zum Ausführen von R-Modellen und eine Excel-ähnliche UI, um die für den Wettbewerb mit Uber China nötigen Daten schnell zu verarbeiten, doch nach dem Verkauf von Uber China an Didi wurde die Funktion bald wieder entfernt
- R-Crusher war ein internes System, das den instabilen Ablauf ersetzen sollte, bei dem Data Scientists Vertica-Daten auf Laptops herunterluden und R-Modelle über Nacht laufen ließen, durch ein API-basiertes Ausführungstool
- Die China-City-Teams waren an Excel-Dateien zur Berechnung von Fahrer-Incentives gewöhnt, daher implementierte das Team statt Hunderte bis Tausende Formeln direkt in JavaScript zu übertragen eine Spreadsheet-Engine, die XLS-Dateien und Formeln im Browser ausführt
- Dass die Ergebnisse leicht von Excel abwichen, lag daran, dass Data Scientists zirkuläre Referenzen für lineare Regression verwendeten; angepasst wurde das durch iterative Berechnung bis zur Konvergenz wie in Excel
- Selbst gut geschriebener Code kann entfernt werden, wenn das Business-Problem, das er lösen sollte, verschwindet; der Wert von Engineering liegt näher an der Problemlösung als an der Lebensdauer des Codes
Internes Datentool, das Uber China stützte
- Nach dem Einstieg bei Uber im Jahr 2016 arbeitete ich im Crystal-Ball-Team als erster Frontend-Ingenieur
- Das Team war etwa vier Personen groß und die meisten hatten einen starken Backend-Fokus
- Meine Aufgabe war es, interne Tools in UIs zu verwandeln, die Menschen im Unternehmen tatsächlich nutzen konnten
- Damals luden Data Scientists Daten aus Vertica herunter und ließen R-Modelle über Nacht auf mehreren Laptops laufen
- Am Morgen kamen nur von den Laptops, auf denen das Modell nicht abgestürzt war, Daten heraus, die an diesem Tag vielleicht genutzt werden konnten
- Auf den fehlgeschlagenen Laptops wurden die benötigten Daten nicht erzeugt, was dazu führte, dass das Unternehmen Geld verlor
- Das Team entwickelte R-Crusher, ein System, das eher einem CI-System ähnelte, das Code per API-Aufruf herunterlädt, ausführt und Ergebnisdateien erzeugt
- Das Frontend von R-Crusher, Wesley, war schon wenige Wochen nach meinem Einstieg in einer ersten Version bereit
- In den folgenden sechs bis sieben Monaten kamen User-Features, Debugging-Tools und der Ausbau des Frontend-Teams hinzu
Der chinesische Markt und die Berechnung von Fahrer-Incentives
- 2016 waren zwei große Themen innerhalb von Uber die Neuschreibung bzw. das Redesign der App und Uber China
- Die Arbeit des Crystal-Ball-Teams diente letztlich dazu, Uber China zu unterstützen
- R-Crusher war ein Tool, um die für den Wettbewerb mit Didi nötigen Daten zu beschaffen
- China war für Uber eine wichtige Chance, und ein Teil der benötigten Daten sollte aus R-Crusher kommen
- Im Sommer kam eine neue Anforderung herein
- Es gab ein Modell, das über Nacht Prognosedaten zur Fahrtnachfrage in chinesischen Städten erzeugte
- Diese Daten waren für sich genommen nicht nützlich; erst wenn sie in einen bestimmten Tab einer Excel-Tabelle eingefügt wurden, entstand daraus ein interaktives Tool zur Berechnung von Fahrer-Incentives
- Die Finanzverantwortliche verlangte, diese Tabelle in Wesley einzubauen
- Die City-Teams könnten nur Excel nutzen und verlangten: „Macht es wie Excel.“
- Wir erklärten, dass dafür zu wenig Engineering-Zeit vorhanden sei, bekamen aber zur Antwort, dass ohne dieses Tool jeden Tag Millionen Dollar verloren gingen
Excel im Browser nachbauen
- Es blieb keine Zeit, die Tabelle im Backend in Python- oder R-Code zu übertragen, also mussten wir im Frontend viel JavaScript schreiben
- Grundlage war ein früherer Prototyp namens Box Sums, den ich bei Box gebaut hatte
- Er hatte eine einfache Spreadsheet-UI auf React-Basis und eine grundlegende Formel-Engine
- Wenn man eine XLS/XLSX-Datei auf die Seite zog, wurde ihr Inhalt mit einer Node-Bibliothek geparst
- Die Umsetzung für Uber zielte nicht auf Excel selbst, sondern auf ein Verhalten möglichst nah an Excel
- Einlesen einer XLS-Datei als Eingabe
- Ausführen von Excel-Formeln auf den Daten
- Das Backend lieferte Fahrtnachfragedaten als zweidimensionales Array, und das Frontend speiste sie wie einen versteckten Tab in die Formel-Engine ein
- Alle Zellen außer denen, die Nutzer bearbeiten mussten, wurden schreibgeschützt
- Entscheidend war, Hunderte bis Tausende dichter Formeln nicht direkt von Hand in JavaScript zu übersetzen
- Im Implementierungsprozess wurden die Formeln aus der XLS-Datei extrahiert und die nötigen Funktionen und Syntaxelemente zur Formel-Engine hinzugefügt
-
Erweiterung der Excel-Syntax
- Absolute Zellreferenzen
- Zellreferenzen auf andere Sheets
- Spreadsheet-Syntax, die in der bestehenden Box-Demo nicht vorhanden war
-
Fast richtig, aber falsche Zahlen und zirkuläre Referenzen
- Beim ersten Vergleich unterschieden sich die Ergebnisse von Excel und unserer Engine nur minimal
- Wenn Excel
3.03ausgab, lieferte unsere Ausgabe3.01 - Wenn Excel
1.002ausgab, lieferte unsere Ausgabe1.000
- Wenn Excel
- Fast richtige Werte waren schwieriger als klar falsche Werte
- Wahrscheinlicher war kein einfacher Logikfehler, sondern ein subtiler Unterschied in der Berechnung
- Die Unit-Tests liefen erfolgreich, und auch Unterschiede zwischen JavaScript-Doubles und der Fließkommadarstellung von Excel waren nicht die Ursache
- Nach einer Rückfrage bei einem Data Scientist wurde die Ursache klar
- Die Tabelle nutzte zirkuläre Referenzen, um lineare Regression auszuführen
- Excel behandelt zirkuläre Referenzen nicht immer als Fehler
- Wenn die berechneten Werte bis unter ein bestimmtes Epsilon konvergieren, stoppt Excel die iterative Berechnung und behandelt das Ergebnis als erfolgreich
- Die Implementierung wurde so geändert, dass ein zirkulärer Abhängigkeitsgraph erkannt und der Unterschied zwischen dem vorherigen und dem neuen Berechnungswert verglichen wurde
- War der Unterschied klein genug, wurde der neue Wert verwendet
- Andernfalls wurde die Zahl der Iterationen erhöht und weitergerechnet
- Der Schwellenwert für die maximale Iterationszahl lag bei 1000
- Die Änderung dauerte etwa anderthalb Tage, danach stimmte die Ausgabe mit Excel überein
- Es wurden Tests geschrieben und alles in Wesley integriert
- Das Projekt wurde in der zweiten Juliwoche ausgeliefert
Sicherheitsanforderungen nach dem Launch und die plötzliche Abschaffung
- Das Tool wurde tatsächlich ausgerollt, und Mitglieder der Uber-China-City-Teams loggten sich ein und nutzten es
- Soweit ich weiß, wurden die erzeugten Zahlen für Fahrer-Incentives verwendet
- Der Zeitpunkt war die dritte Juliwoche
- In der letzten Juliwoche beanstandete die Finanzverantwortliche, dass beim Klick auf Zellen die Formeln sichtbar wurden
- Es wurde die Sorge geäußert, ein Didi-Mitarbeiter könnte sich als Uber-China-Praktikant bewerben und die Daten abziehen
- Dieses Bedrohungsmodell war dem Engineering-Team vorher nicht mitgeteilt worden
- Um die Formeln vollständig zu schützen, hätte die Berechnung auf den Server verlagert werden müssen, was aber außerhalb des angefragten Umfangs lag
- Als Sofortmaßnahme wurde im UI verhindert, dass Formeln beim Klick auf Zellen sichtbar sind
- In der ersten Augustwoche 2016 wurde Uber China an Didi verkauft
- Viele Mitarbeitende erfuhren es zuerst durch News-Benachrichtigungen
- Einige Stunden später wurde der Deal per interner E-Mail angekündigt
- Mit dem Ende von Uber China wurde diese UI aus Wesley entfernt
- Es war eine maßgeschneiderte UI für einen Daten-Workflow, der nie wieder ausgeführt werden würde
- Eine weitere Anfrage, Excel im Browser nachzubauen, gab es nicht
Problemlösung ist wichtiger als die Lebensdauer von Code
- Damals fühlte ich keinen großen Verlust oder große Enttäuschung
- Mein erster Gedanke war eher, den Code auf GitHub veröffentlichen zu wollen, und danach ging ich zur nächsten Aufgabe über
- Es blieb nur ein kleines Bedauern darüber, dass der mit viel Aufwand geschriebene Code nur kurz genutzt wurde und dann verschwand
- Der Code, den Ingenieure schreiben, wird irgendwann zu Legacy Code
- Irgendjemand könnte irgendwann sogar Freude daran haben, ihn zu entfernen
- Selbst bei gutem Code ist langes Fortbestehen nicht das eigentliche Ziel
- Als Ingenieur zu wachsen, hängt damit zusammen, Technik besser dafür einzusetzen, Business Value zu schaffen
- Business Value kann auf viele Arten entstehen: durch technische Ergebnisse, Zusammenarbeit, Mentoring oder Unterstützung des Teams
- Nach dem Verschwinden von Uber China gab es für dieses Projekt keinen weiteren Business Value mehr zu schaffen
- Es weiter voranzutreiben hätte weder mir noch dem Unternehmen geholfen
- Der DevOps-Ausdruck „Cattle, not pets“ passt auch auf Code
- Code ist ein Mittel, um Arbeit zu erledigen, und wenn diese Arbeit nicht mehr nützlich ist, sollte der Code bereit sein, in den Ruhestand zu gehen
- Wenn man Code aus emotionalen Gründen wie ein Haustier behandelt, bewegt man sich gegen das Verständnis des Business
Welche Fragen ein abgeschafftes Projekt hinterlässt
- Ein entferntes Projekt muss nicht automatisch als Fehlschlag gelten
- Zurück bleibt bei eingestellter Arbeit eine Reihe von Fragen
- Wurde etwas gebaut, das die Projektbeschränkungen nicht erfüllte?
- Wurde zwar das Gewünschte gebaut, aber war die ursprüngliche Anforderung falsch?
- Wurde das Kernproblem falsch verstanden?
- Löste die angeforderte Lösung tatsächlich die Bedürfnisse der Endnutzer?
- Gab es Fragen, die den Stakeholdern nicht gestellt wurden?
- Waren die Erwartungen ungenau oder mehrdeutig?
- War wirklich so viel Robustheit nötig, wie geliefert wurde?
- Hätte eine einfachere oder weniger clevere Lösung ausgereicht?
- Wurden die Erfolgskriterien falsch gesetzt?
- Gab es neben „Baut, worum gebeten wurde“ noch andere Erfolgskriterien?
- Wenn man das Ende eines Projekts nur als Scheitern sieht, verpasst man die Chance zu lernen, an welcher Stelle nichttechnische Probleme schiefgelaufen sind
- Selbst sorgfältig gebaute Bausteine können entfernt werden, wenn sie im größeren System nicht reibungslos funktionieren
1 Kommentare
Hacker-News-Kommentare
Das beste Zitat war dieses: „Leute, die bei Didi arbeiten, bewerben sich als Praktikanten bei Uber China und ziehen dann unsere Daten ab. Wir können sie die Formeln nicht sehen lassen. Sonst kopieren sie genau das, was wir tun!“
Das stimmt wirklich. Amerikaner wissen kaum, welches Ausmaß Wirtschafts- und Industriespionage in China jeden Tag hat. Irgendwann Mitte der 2000er reagierte ich auf einen separaten Sicherheitsvorfall bei einem Technologieunternehmen, dessen Namen ich nicht nennen kann. Dabei hörte ich: „Wir haben in Xinjiang ein Technologiezentrum eröffnet, und in letzter Zeit gehen auffällig viele Zugangsausweise verloren.“ Als ich fragte: „Habt ihr schon einmal darüber nachgedacht, dass sie vielleicht nicht verloren gehen, sondern gegen Geld verkauft werden?“, folgte Schweigen.
Ich weiß nicht, ob die Führungskräfte es wissen und es ihnen egal ist, oder ob sie einfach inkompetent sind, aber China hat Industriespionage im großen Stil produktisiert. Kürzlich wurde auch GE Aviation Opfer: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...
Danach gründeten sie in China Firmen, holten chinesische Investoren an Bord und bauten für den chinesischen Markt nahezu identische Produkte. Beispiele dafür sind Thoratec/Abbot Heartmate III und CH Biomedical sowie Auris/Verb/J&J Robotic & Digital Solutions und Renovo Surgical.
Ironischerweise versuchen einige dieser Unternehmen, nachdem sie in China erfolgreich waren, auch in die USA und nach Europa zu verkaufen und dort zu konkurrieren. Das ist inzwischen weder geheim noch eine Hinterzimmergeschichte; in unserer Branche geschieht es ganz offen und wird größtenteils als „so läuft das eben“ hingenommen.
Ein weiterer Punkt ist, dass es für ausländische Unternehmen sehr schwierig ist, ihre Assets zu schützen, wenn sie in China Geschäfte machen. Deshalb versuchen kluge Unternehmen oft gar nicht erst, es selbst zu machen, sondern lizenzieren für den chinesischen Markt an chinesische Unternehmen. So besteht wenigstens eine Chance, dass nicht alles gestohlen wird.
Früher holte die Agentur, bei der ich arbeitete, einmal einen Industriedesigner dazu, um ein hübsches Gehäuse für iBeacon-Hardware zu entwerfen. Das Ergebnis war großartig.
Wir ließen ein chinesisches Unternehmen den Spritzguss übernehmen, und die Muster waren ziemlich gut, also entschieden wir uns dafür. Ein paar Wochen später sahen wir dann auf Alibaba/AliExpress, dass unser Gehäuse verkauft wurde.
Das soll nicht heißen, dass der Westen oder andere Länder perfekt wären, aber darum geht es hier gerade nicht. Alle Leute, die ich kenne und die mit chinesischer Fertigung und chinesischem Business gearbeitet haben, haben Dinge erlebt wie „sie haben es kopiert“, „sie haben unsere Arbeit an jemand anderen verkauft“ oder „sie haben eine niedrigere Qualität von x geliefert als vereinbart“.
Die Gegenargumente laufen immer auf „Aber der Westen macht doch auch X“ oder „Das ist rassistisch“ hinaus.
Chinesische Unternehmen, insbesondere solche, die auf Ali-X verkaufen, lieben diese Struktur wirklich. Denn sie können geistiges Eigentum kostenlos nehmen und den ursprünglichen Gerätehersteller preislich verdrängen. Auch Designs von Makern auf Tindie und ähnlichen Plattformen werden oft kopiert und tauchen dann auf Ali auf.
https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
Beim Lesen dieses Beitrags hatte ich erwartet, dass es um das Entfernen und Löschen von komplexem Custom-Code geht, aber anders als erwartet ist der Autor als Engineer gewachsen.
Das DevOps-Sprichwort „Cattle, not pets“ passt hier perfekt. Code und die damit gebauten Produkte sind keine Haustiere, sondern Nutzvieh. Sie erledigen Arbeit, und wenn diese Arbeit nicht mehr nützlich ist, sind sie bereit für den Ruhestand. Wenn man Code aus sentimentalen Gründen wie ein Haustier behandelt, arbeitet man den Interessen des Business direkt entgegen.
Viel Code macht Spaß beim Schreiben, und viele Probleme machen Spaß beim Lösen. Aber ein Business, besonders ein Startup, muss extrem fokussiert sein. Meine Karriere besteht im Grunde daraus, in Konferenzräumen zu sitzen und jungen, leidenschaftlichen Engineers zu sagen, sie sollen es nicht bauen. Das ist ein bisschen deprimierend, aber auch absolut notwendig.
Ein guter Engineer kann mit cleverem Code jedes Problem lösen. Ein großartiger Engineer versteht, dass manches Problem in Wahrheit gar keines ist und dass ein täglich aktualisierter XLS-Download-Link vielleicht gereicht hätte.
Ich baute ein Monitoring-System für einen intern gehosteten Dienst, und mein Chef wollte ein kleines Utility kaufen, das einen winzigen Teil unserer Umgebung überwachte. Ich war etwas beleidigt, dass er dafür Geld ausgeben wollte, obwohl ich es selbst bauen konnte.
Mein Chef fragte: „Wie lange würdest du brauchen, um das zu schreiben und zu testen?“ Ich antwortete: „Wahrscheinlich eine Woche, vielleicht etwas länger, wenn etwas Kniffliges auftaucht.“ Darauf fragte er: „Das Tool kostet 500 Dollar. Was kostet deine 40-Stunden-Woche?“
Da fiel bei mir der Groschen, und seitdem habe ich in der Firma nichts mehr selbst gebaut, was man günstiger kaufen konnte.
Auch die Checkliste unten auf der Substack-Seite reicht für diese Art von Anforderungsklärung nicht aus. Diese Fragen beschreiben nur die Situation; allein dadurch, dass man sie stellt, wäre man nicht bei dieser einfachen Lösung gelandet. Checklisten-Denken ist eine Krücke und macht Probleme unnötig kompliziert.
Die wichtigen Signale hier waren allesamt organisatorischer und sozialer Natur; das war kein Problem, das sich durch einen besseren Prozess lösen ließ. Wer nicht an Implementierungsdetails beteiligt ist, kann keine Fragen zu Implementierungsdetails beantworten.
„Baut es einfach wie Excel“ ist eine minderwertige Antwort von jemandem mit völlig anderen Zielen. Man hätte mit Personen sprechen müssen, die näher an den tatsächlichen Nutzern sind, und von dort aus Gegenargumente entwickeln. Gefehlt hat der Mut, schwache Annahmen zu erkennen und absichtlich keinen Code zu schreiben, bis die Details so weit festgezurrt sind, dass alle Beteiligten zustimmen können. Man darf der „verantwortlichen Person“ nicht einfach Ja sagen.
Schon 2006 habe ich lange Gespräche geführt, um jemanden davon abzubringen, diesen Weg zu gehen, und 2026 wird es wieder jemand versuchen.
Die Fähigkeit, innezuhalten und zu fragen: „Wie haben andere dieses genaue Problem gelöst?“, ist ein sehr großer Teil davon, als Entwickler zu wachsen; ich wünschte, Schulen würden stärker darauf eingehen.
Allein aus der Beschreibung, dass es innerhalb einer kurzen Frist rechtzeitig und erfolgreich fertiggestellt wurde, kann man nicht schließen, dass die Implementierungsentscheidung schlecht war. Eher war es so erfolgreich, dass zu viele Excel-Funktionen implementiert wurden, und später wurde das durch Entfernen behoben. Wie hätte man das bei einem XLS-Download-Link entfernen sollen?
Der Kernpunkt ist, sich nicht zu sehr an Code zu klammern, und in manchen Situationen kann das heißen: „Nicht selbst bauen, sondern einen XLS-Download-Link verwenden.“ Aber das ist nicht alles.
Die Stellen „Nichts geschah, aber ich hob den Code für den Tag auf, an dem ich ihn irgendwann nutzen würde. Meine Idee war, diesen Code für Ubers Zwecke zurechtzuschneiden“ und „Meine erste Reaktion war, den Code auf GitHub zu veröffentlichen“ sind ziemlich erstaunlich.
Gehört dieser Code nicht Box oder Uber? Der Autor erwähnt nicht, dass er vor der Veröffentlichung unter der MIT-Lizenz eine Erlaubnis eingeholt hat.
Wenn Uber Code haben will, der nicht bei ihnen entstanden ist, aus mehreren Tausend Zeilen JavaScript besteht, mehr als ein halbes Jahr alt ist und weniger als einen Monat genutzt wurde, können sie mir einen Brief schicken.
Die Stelle „Er konnte einfach nicht glauben, dass ich eine vollständige Spreadsheet-Engine geschrieben hatte, die im Browser läuft“ fällt auch mir schwer zu glauben – und das ist nicht positiv gemeint.
Mit Apache POI kann man Excel headless ausführen. Man kann in Java Sheets laden und programmatisch damit interagieren; bei einem früheren Arbeitgeber habe ich es aus genau demselben Grund verwendet. Funktionen, Zellbezüge usw. funktionierten alle problemlos.
Er hatte einfach Glück, das „circ“-Problem zu finden. Was ist mit all den kleinen versteckten Eigenheiten von Excel, auf die man künftig stoßen wird? Will man wirklich einen vollständigen Excel-Klon in JS bauen und warten? Ist das wirklich das Ziel des Frontend-Teams?
Mit ein wenig Recherche hätte man hier wohl über 90 % der Arbeit vermeiden können. Und nebenbei hätte das auch das Backend-Team übernehmen können.
Uber betrieb eigene Rechenzentren. Eine Windows-Maschine oder VM zu beschaffen, auf der echtes Excel läuft, hätte ein Wunder erfordert. Einen neuen Frontend-Service konnte ich in etwa 30 Minuten hochziehen, und es gab auch schon Code, der teilweise lief – ich habe also nicht komplett bei null angefangen. Außerdem musste man berücksichtigen, dass dieses System von mehreren Personen mit unterschiedlichen Datensätzen gleichzeitig genutzt werden sollte.
Wenn weiter immer mehr Features und Excel-Gleichwertigkeit verlangt worden wären, hätte ich das überdacht, aber dazu kam es nicht.
Ich erwarte nicht, dass viele Leute dieselbe Entscheidung getroffen hätten wie ich. Aber sie funktionierte, und sie funktionierte überraschend gut. Wenn aus dem Artikel nur „es war ein großes, kompliziertes Projekt“ hängen geblieben ist, dann hat der Artikel die Botschaft, die ich vermitteln wollte, nicht richtig transportiert.
Ich hätte wohl stärker auf der UI-Spezifikation bestanden und dafür argumentiert, im Hintergrund Excel laufen zu lassen. Aber wenn überall viele Zahlen eingegeben werden müssen, ist das natürlich eine vertraute UI.
Diesen Artikel über den Bau eines Spreadsheets in 100 Zeilen F# fand ich immer unterhaltsam: https://tomasp.net/blog/2018/write-your-own-excel/ Das auf den hier benötigten Funktionsumfang zu erweitern, ist machbar.
Am Ende wurde als UI für das Modell ein selbst gebauter „Excel“-Klon erstellt, weil „die City-Teams nur Excel bedienen können“.
Ich hätte es umgekehrt gemacht. Ich hätte Excel mit den vom Modell ausgegebenen Daten verbunden, damit die City-Teams weiterhin echtes Excel nutzen können. So scheinen es die meisten Finance-Teams zu machen.
Für alle Interessierten: Dokumentation zu zirkelbezüglichen Verweisen in Excel: https://support.microsoft.com/en-us/office/remove-or-allow-a...
Wenn man mit iterativer Berechnung nicht vertraut ist, will man einen Zirkelbezug wahrscheinlich nicht einfach stehen lassen. Man kann iterative Berechnung einschalten, muss dann aber festlegen, wie oft Formeln neu berechnet werden sollen. Wenn man iterative Berechnung aktiviert, ohne die maximale Anzahl der Iterationen oder den maximalen Änderungswert zu ändern, beendet Excel die Berechnung nach 100 Iterationen oder sobald alle Werteänderungen im Zirkelbezug zwischen Iterationen unter 0,001 fallen – je nachdem, was zuerst eintritt. Die maximale Anzahl der Iterationen und die zulässige Änderung lassen sich jedoch steuern.
Ich frage mich, ob der Autor die Situation anders sehen würde, wenn Uber oder Box diesen Code als ihren eigenen beansprucht hätten. Auch wenn der Code sein tatsächliches Potenzial nie entfaltet hat, dürfte es zumindest eine gewisse Katharsis sein, dass die ganze Welt ihn sehen und anerkennen kann.
Ich habe als Praktikant einmal eine komplette Programmiersprache gebaut. Sie hatte Lazy Evaluation und Garbage Collection, dazu anwendungsspezifische Merkwürdigkeiten wie MAC-Adressen ohne Anführungszeichen als gültige Syntax.
Bytecode oder JIT gab es nicht; der Interpreter lief durch den Syntaxbaum und pushte/poppte Werte auf einen Stack, aber für unsere Zwecke war das schnell genug. Der Interpreter war in reinem ANSI C geschrieben, und Valgrind war damit sehr zufrieden.
Vielleicht ist sie völlig in Vergessenheit geraten, vielleicht wurde sie auch zum Kern der technischen Infrastruktur dieser Firma. Der Code hat das von mir geschriebene Air-Gap-Labor nie verlassen, daher kann ich es nicht wissen. Als ich vor drei Jahren frisch von der Uni kam, war das mit Abstand das Coolste an „tatsächlich nützlicher Software“, das ich je geschrieben hatte, und es gehört immer noch zur Spitzengruppe. Manchmal frage ich mich, was daraus geworden ist.
Der Autor scheint dem Irrtum zu unterliegen, dass es das Unternehmen rechtlich bindet, wenn er einen mittleren Manager, vielleicht sogar einen höheren Manager, fragt: „Wollen Sie das haben?“, und dieser Manager „Nein“ sagt.
Der Satz „Es ist leicht, besonders cleveren oder eleganten Code wie ein Meisterwerk zu behandeln. Vielleicht ist er tatsächlich ein schönes Schmuckstück. Aber wir Ingenieure sind nicht im Geschäft, schöne Schmuckstücke zu schaffen, sondern Ergebnisse“ hat mich angesprochen.
Allerdings weiß jeder, der meinen Code gesehen hat, dass ich möchte, dass sowohl der Code als auch seine Funktion sehr hübsch sind. Meistens schreibe ich Code, den ich später selbst warten muss, also sollte ich ihn auch ein Jahr später noch verstehen können.
Ich bin gerade in der Endphase eines Projekts, das ich hier nicht vorstellen werde und für das ich auch nicht groß Anerkennung beanspruchen will, aber es ist wirklich ein verdammt gutes Ding. Der Grund dafür ist, dass niemand dafür bezahlt und niemand damit Geld verdient.
Geld ruiniert alles – und macht zugleich alles möglich.
Ein wirklich hervorragender Beitrag aus der Perspektive des früheren Uber-BI-Teams. Ich war damals im Vertica-Team, und der Aufwand, der in Incentives floss, war schwindelerregend. Dass durch Downtime, Produktfunktionen und Engineering-Bandbreite täglich Millionen von Dollar verloren gingen, war ein häufiges Thema.
Besonders zur Zeit von Uber China wäre es auch sehr naheliegend gewesen, dass ein Director explizit eine Tabellenkalkulation als UI verlangte. Ich persönlich habe jeden Monat FX-Preise aus einer per E-Mail ans Team geschickten Tabelle in Vertica geladen. Weil die Bandbreite fehlte, den Kontrollfluss per automatischer Erfassung umzukehren, blieb dieser Prozess über ein Jahr lang bestehen.
Die Aussage „Bis heute habe ich kein so gut gestaltetes internes Anwendungssystem gesehen wie das von Uber. Von null bis zu Hello World auf einer Subdomain von *.uberinternal.com mit vollständigem CI/CD dauerte es keine 30 Minuten“ hat mir ein wenig das Herz erwärmt.
Ich war damals bei Uber an all dem beteiligt.