Ingenieure können sich beim Aufbau eines Ledgers keine Startup-Fehler leisten

 (news.alvaroduran.com)
1 Punkte von GN⁺ 2024-11-30 | 1 Kommentare | Auf WhatsApp teilen
  • In Fintechs, die mit echtem Geld umgehen, können schon Abweichungen von wenigen Cent das Vertrauen der Nutzer zerstören; ein Startup für Aktienhandel, das Transaktionen mit einfacher Buchführung erfasste, bekam es mit dem Problem der dancing cents zu tun
  • Da ein Ledger mit einfacher Buchführung nur Geldein- und -ausgänge festhält, ist es schwer nachzuvollziehen, wodurch Differenzen entstehen, etwa durch Devisen, das rounding to even des Brokers oder FINRA-TAF-Gebühren
  • Ein Ledger mit doppelter Buchführung betrachtet Geld so, dass es immer von einem Konto zu einem anderen wandert, und trennt Accounts, Entries und Transactions, um Herkunft und Ziel gemeinsam zu erfassen
  • Wenn die Zustände pending, discarded und posted von Entries sowie die Buchungsbedingungen von Transactions klar definiert sind, lassen sich Teilausfälle und ausgleichende Entries sicherer handhaben
  • Ein Ledger ist sowohl eine Schnittstelle für die Rechnungslegung als auch ein system of record, das die Konsistenz des Geldes schützt; beim Skalieren wächst daher die Spannung zwischen Verfügbarkeit und starker Konsistenz

Ein paar Cent Differenz zerstörten das Vertrauen der Nutzer

  • Das Startup, das eine Aktienhandelsplattform baute, folgte dem Prinzip „make it work, make it right, make it fast“ und entwickelte nicht von Anfang an ein System der doppelten Buchführung
  • Kurz nach dem Launch wichen die Beträge, die der Vendor erkannte, und die Beträge im internen System jeweils um ein paar Cent voneinander ab
    • Intern nannte man das dancing cents
    • Wenn ein Nutzer Apple-Aktien im Wert von 5 Dollar kaufte, die Order aber als 4,98 Dollar angezeigt wurde, wandte er sich sofort an den Kundensupport
  • Der Kern des Problems lag weniger im Verlustbetrag als in Vertrauen und Wachstum
    • Verärgerte Nutzer empfahlen den Dienst nicht weiter, und das Wachstum des Startups wurde gebremst
    • Der CEO wies an, dass der Kundensupport bei fehlerhaften Transaktionen ein paar Cent manuell erstatten sollte
    • Dafür wurde sogar ein Slack-Bot gebaut

Geld verfolgt nicht nur den aktuellen Saldo, sondern auch zukünftigen Wert

  • Ein Ledger ist ein System zur Nachverfolgung von Geld
  • Geld wird nicht nur als einfacher aktueller Saldo benötigt, sondern auch, um künftig zu erhaltenden oder zu gebenden Wert auszudrücken
    • Konzeptionell ist Geld ein zukünftiger Vermögenswert
  • Wenn man nur Ein- und Auszahlungen wie „der Nutzer hat 5 Dollar gezahlt“ oder „der Nutzer hat 6 Dollar gezahlt“ erfasst, reicht das nicht aus, um tatsächliche Finanzflüsse zu erklären
  • Banküberweisungen sind nach Internetmaßstäben langsam, und viele Banken rechnen Überweisungen erst am nächsten Geschäftstag ab
    • Sobald die Zahlung abgeschlossen ist, besteht die Gewissheit, dass man irgendwann Geld erhalten wird
    • Die Aktie muss jedoch jetzt über den Broker gekauft werden
    • Der pending Betrag, der einige Tage später abgerechnet wird, und der Betrag, der sofort an den Broker hinausgeht, müssen gleichzeitig dargestellt werden
  • Bei einfacher Buchführung ist ein Rollback im Fehlerfall sehr schwierig, und in manchen Corner Cases kann man nicht einmal versuchen, zurückzurollen

Warum ein Ledger mit einfacher Buchführung das Debugging verhindert

  • Ein Ledger mit einfacher Buchführung kann Geldflüsse zeigen, aber nicht erklären, warum sie entstanden sind
  • Um die Ursache einer bestimmten Geldbewegung zu finden, musste man Daten aus mehreren Modellen zusammenfügen, und in manchen Fällen war nicht einmal das möglich
  • Ein Ledger mit doppelter Buchführung hält gemeinsam fest, was passiert ist und warum es passiert ist
    • Jede Geldbewegung erfolgt von einem Konto zu einem anderen
    • Erfasst wird, aus welchem Konto jeder Cent stammt und in welches Konto er geflossen ist
  • Das Problem der dancing cents war in einem System mit einfacher Buchführung schwer zu lösen
    • Es war schwer zu erkennen, ob die verschwundenen Cent durch Devisen entstanden waren
    • Es konnte am rounding to even mechanism des Brokers liegen
    • Es konnte an den am Tagesende erhobenen FINRA TAF fees liegen
  • Wenn man nicht versteht, wie ein System funktioniert, ist es auch schwer, Bugs zu beseitigen

Ledger-Datenmodell: Accounts, Entries, Transactions

  • Viele Ingenieure legen Beträge beim ersten Nachverfolgen von Geld direkt im Domänenmodell ab
    • Etwa indem sie einem Order-Objekt ein price-Attribut geben oder einer expenses-Tabelle eine amount-Spalte hinzufügen
    • Das ist der Ansatz balance as property
  • Dieser Ansatz funktioniert anfangs schnell, doch mit der Zeit werden Reporting komplex und langsam sowie Payment Processing und Analysen schwieriger
    • Wenn nächtliche Report-Jobs mehrere Stunden dauern, kann dieser Ansatz die eigentliche Ursache sein
  • Ein Ledger sollte besser als separates Datenmodell behandelt werden, aus dem sich alle Finanztransaktionen des Systems ableiten lassen
  • Drei Entitäten bilden die Grundstruktur
    • Accounts: Buckets für Wert und eine Perspektive darauf, wie sich Wert im Zeitverlauf verändert
    • Entries: Geldflüsse zwischen Accounts, die immer einen Austausch von Wert darstellen
    • Transactions: Einheiten, die sicherstellen, dass Entries korrekt gepaart und verarbeitet werden

Zustände und Unveränderlichkeit von Entries

  • Entries können drei Zustände haben: pending, discarded und posted
  • Ein Entry wird immer im Zustand pending erstellt
    • Ausgetauschter Wert
    • Richtung als credit oder debit
    • Informationen zum referenzierten account
  • Die Richtung eines Betrags durch positive und negative Zahlen auszudrücken, ist ein häufiger Fehler
  • Entries sind grundsätzlich unveränderlich, ein pending Entry kann jedoch discarded werden, um einen posted Entry zu erstellen
  • Eine Alternative besteht darin, einen reversal Entry zu erstellen, um einen pending Entry rückgängig zu machen
    • Der Ansatz mit reversal Entry kann die Kontohistorie jedoch unübersichtlich machen
    • Mit dem Zustand discarded genügt es, beim Betrachten aktueller Entries Einträge mit gesetztem discarded_at auszuschließen, ohne Historie zu verlieren
  • In einem System mit doppelter Buchführung entspricht die Summe der nicht verworfenen credit Entries der Summe der nicht verworfenen debit Entries
    • Konzeptionell bedeutet das: Egal, wie man Geld innerhalb einer Tasche verschiebt, der Gesamtbetrag bleibt gleich
  • Einige spezielle Accounts, die die Außenwelt darstellen und in der Profit and Loss statement zusammengeführt werden, können ausnahmsweise nicht ausgeglichen werden

Transactions und Umgang mit Teilausfällen

  • Entries werden paarweise erzeugt, und Transactions stellen sicher, dass dieser Prozess wie beabsichtigt abläuft
  • Eine Transaction wird nur dann posted, wenn die verknüpften Entries posted oder discarded sind und durch posted Entries ersetzt wurden
  • Eine Transaction mit Teilausfall kann semantisch durch compensating Entries rückgängig gemacht werden
  • Dieser Ansatz passt gut zum Saga pattern
    • Saga tauscht Atomarität gegen Verfügbarkeit
    • Statt einer langsamen Transaktion, die mehrere Tabellen sperrt, wird der Prozess in kleinere Einzeloperationen und Zwischen-Checkpoints aufgeteilt
    • Dazwischen können andere Transaktionen arbeiten, was den Durchsatz verbessert

Accounts und normal balance

  • Aus der Perspektive eines einzelnen Account sieht ein Ledger wie ein System mit einfacher Buchführung aus
    • Ein Account hat eine One-to-many-Beziehung zu mehreren Entries
    • Der Gesamtsaldo muss mit der Summe der einzelnen Salden der verknüpften Entries übereinstimmen
  • Je nach normal balance eines Account unterscheidet sich die Berechnung des Gesamtbetrags
  • Das Koppeln von Plus- und Minuszeichen an Entry-Beträge sollte buchhalterisch vermieden werden
    • Bei manchen Accounts ist ein net credit normal, bei anderen ein net debit
    • Beispielsweise kann bei einem Bank-Cash-Account ein net debit normal sein, doch bei Überziehung kann er negativ werden
  • Eine normal credit balance bedeutet, dass es normal ist, wenn die Summe der verknüpften credit Entries größer ist als die Summe der debit Entries
  • Eine normal debit balance ist das Gegenteil

Die Spannung zwischen Buchhaltungssystem und Engineering-System

  • In einem Ledger koexistieren zwei Systeme mit unterschiedlichen Anforderungen
    • Accounting system: die von außen sichtbare Schnittstelle des Ledgers
    • Engineering system: die Implementierung, durch die der Ledger sich selbst sieht
  • Das Accounting system stellt aggregierte Daten aus mehreren Perspektiven bereit
    • Reporting
    • Financial ratios
    • Business Intelligence
  • Das Engineering system muss Konsistenz und Korrektheit der Daten gewährleisten
    • In einem Fintech-Unternehmen dient der Ledger als source of truth, ähnlich wie das CRM des Vertriebsteams
  • Der Grund, warum das Skalieren eines Ledgers schwierig ist, liegt darin, dass die Anforderungen beider Systeme unterschiedlich sind
    • Das Accounting system verlangt hohe Verfügbarkeit und niedrige Latenz
    • Das Engineering system verlangt starke Konsistenz und schema-on-write-Prüfungen

Buchhaltungsressourcen für Entwickler

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-30
Hacker-News-Kommentare

  • Sagt das mal den Kunden von Synapse. Millionen von Dollar sind verschwunden.
    Banken müssen nach strengen Regeln ihre Bücher abstimmen, damit klar ist, wohin Geld geflossen ist. Fintechs dagegen legen meist ihr eigenes Ledger über ein oder wenige zugrunde liegende FBO-Konten, auf denen Kundengelder gesammelt werden, und verfolgen darüber die Salden der einzelnen Kunden. Im Fall von Synapse war die Summe der Kundensalden im eigenen Ledger deutlich höher als der tatsächliche Saldo der FBO-Konten.
    Viele vermuten Betrug, aber ich würde darauf wetten, dass es einfach ein chaotisches, fehlerhaftes Ledger war. Wenn man einmal Einblick in so etwas hatte, würde man vermutlich nie wieder Geld auf ein Fintech-Einlagenkonto legen; eine echte Bank ist die bessere Wahl. Selbst wenn ein Fintech damit wirbt, dass Einlagen FDIC-versichert sind: Das schützt nur, wenn die zugrunde liegende Bank scheitert, nicht wenn das Fintech den Überblick über dein Geld verliert.
    Hinweis: https://www.forbes.com/sites/zennonkapron/2024/11/08/what-th...

    • 90 Millionen Dollar sind verschwunden und 250 Millionen Dollar wurden eingefroren. Ein großer Teil dieses Geldes könnte Geld gewesen sein, das jemand für die Miete brauchte.
      Andreessen Horowitz hat investiert, und die führen gegen jede staatliche Regulierung einen Krieg der verbrannten Erde.
      https://finance.yahoo.com/personal-finance/synapse-bankruptc...
    • Als ich in einem großen Unternehmen arbeitete, kam es wegen Inkonsistenzen zwischen Transaktionssystemen dazu, dass Geld aus dem Nichts entstand oder verschwand.
      Schon vorher hatte ich erwartet, dass die Codebasis so vermurkst war, dass man solche Dinge nicht sauber nachverfolgen konnte, und stritt mich mit einem Vorgesetzten, der glaubte, alles laufe wie von Zauberhand. Ein paar Tage später kam eine Mail, dass ein Audit zu Buchhaltungsabweichungen gestartet werde.
      JPMC schlug intern den Einsatz von Kryptowährung vor, um Cashflows konsistent zu verwalten; ich weiß aber nicht, wie weit das tatsächlich gediehen ist.
    • Synapse sagt, die eigentlichen Buchhaltungsfehler hätten bei der Bank Evolve gelegen. Dazu gehörten fehlende Transaktionen, nicht gemeldete Lastschriften und Fälle, in denen laufende Transaktionen an Mercury geschickt wurden, während Synapse fälschlich belastet wurde.
      https://lex.substack.com/p/podcast-what-really-happened-at-s...
    • Mir ist einmal Geld von einem HSBC-Konto verschwunden. Es war eine Zahlung zwischen zwei Konten, bei der die doppelte Buchung um einen kleinen Betrag nicht aufging und sich in den Büchern nicht leicht abgleichen ließ.
      Ich habe eine Zeit lang reklamiert, aber sie haben es weder richtig anerkannt noch korrigiert. Ohne Belege vermutete ich eine subtile interne Unterschlagung, aber Inkompetenz ist wohl die plausiblere Erklärung.
    • Auch echte Bankinstitute sind nicht weniger beunruhigend. Vanguard etwa hat vor einigen Jahren einen großen Teil der Entwicklungsarbeit nach Indien ausgelagert.
      Ein Freund, der bei BoA als Systemadministrator gearbeitet hat, sagte, bestimmte Logs hätten sieben Jahre aufbewahrt werden müssen; wenn die Festplatten vollzulaufen begannen, wurden sie aber einfach gelöscht.

  • Als ich bei Google anfing, war eines der Dinge, die ich erst verstehen musste, dass man für Skalierbarkeit Abstriche bei Zuverlässigkeit oder Genauigkeit macht.
    Zuvor hatte ich Abrechnungssysteme oder kleine OLTP-Webanwendungen gebaut und mir Fragen wie tolerierbaren Datenverlust oder eine von null verschiedene Fehlerrate nie gestellt. Schockierender als die Tatsache, dass bei Millionen Requests pro Sekunde einige fehlschlagen, war der Unterschied in der Engineering-Haltung.
    Selbst in diesem Moment könnten ein paar Tausend Menschen Gmail öffnen und es lädt nicht richtig oder sie bekommen einen 500-Fehler. Niemand verfolgt die Ursache nach, weil der Nutzer aktualisiert und mit seinem Tag weitermacht. Umgekehrt: Selbst wenn die Storage-Durability mit 99,99999 % pro Jahr beeindruckend klingt, erleben bei 2 Milliarden Kunden 200 Menschen einen wirklich miserablen Tag.
    Der Wechsel von der Gewohnheit, jeden Fehler in den Logs zu untersuchen, hin zu einer Welt, in der immer alles ein bisschen kaputt ist und man erst die Kosten abwägt, bevor man etwas repariert, war ziemlich schockierend.

    • Ein so niedriges Durability-Niveau ist heute nicht mehr Stand der Technik.
      Eine Faustregel, die ich in ähnlicher Größenordnung oft gesehen habe, ist, über die gesamte Infrastruktur hinweg auf einen Datenverlustfall in 100 Jahren abzuzielen. Die Kosten steigen normalerweise um deutlich weniger als 10 %, aber man braucht jemanden, der Kombinatorik versteht, wenn die Algorithmen zur Datenplatzierung entworfen werden.
      Wenn man das verstehen muss, ist das Copyset-Paper ein guter Ausgangspunkt.
    • Das stimmt im Großen und Ganzen, aber ich habe auch oft die Gegenrichtung gesehen. Besonders wenn Leute aus Social-Media-Unternehmen mit einem sehr lockeren Gefühl für Ausfälle in Finanzanwendungen wechseln; das geht meistens nicht gut aus.
    • Während meiner Zeit bei Google wurde ich einmal ins Android-Team abgeordnet und arbeitete an der Kontaktsynchronisierung. Das Problem, das ich hatte, trat in extrem seltenen Situationen auf, und als ich aggregierte Produktionsdaten zog, sah es so aus, als würde es 0,01 % der Nutzer betreffen.
      Als ich die Lösung vorstellte und diese Fehlerrate nannte, wurde ich gefragt, wie diese 200.000 Android-Nutzer sich davon erholen könnten. Da es keine Möglichkeit zur Wiederherstellung gab und die Kontaktsynchronisierung einfach kaputtgehen würde, hieß es, ich solle es neu entwerfen.
      Die Zahl selbst machte demütig. Es gibt sicher Bereiche, in denen 99,99 % ausreichen, aber ebenso viele, in denen sie nicht ausreichen.

  • Bei solchen Dingen hilft es, von Anfang an die richtigen Leute einzustellen. Man kann nicht einfach haufenweise LeetCode-Experten einstellen und sie dann nicht fragen, ob sie außer dem Abrufen von Datenstrukturen und Algorithmen aus dem Kopf auch tatsächlich das bauen können, was man bauen will.
    Wenn die Leute wissen, wie man so etwas baut, muss man Wachstum nicht opfern, und es wird von Anfang an richtig gebaut.
    Manchmal braucht man Engineers mit einem anderen Ausbildungshintergrund, etwa Rechnungswesen, Finanzwesen oder Biologie. Der wichtigste Teil meiner Karriere war, die Branche, für die ich etwas baue, gründlich zu verstehen und Fachexperten zu kennen, die die wirklich wichtigen Fragen stellen können. Das ist Problemlösung und Engineering; der Rest ist Programmieren/Coding.

    • Ich glaube, ich habe auf HN noch nie einen Beitrag gesehen, der meinen aktuellen Alltag so erschreckend genau beschreibt und dem ich zugleich völlig zustimme.
      Den Großteil meiner Karriere habe ich im Überschneidungsbereich von Technologie und Finanzwesen verbracht, vor allem bei der Einhaltung von Sales- und Use-Tax-Vorschriften. Dabei war mir gar nicht ausreichend bewusst, wie stark mich Buchhalter, Controller und Anwälte geprägt haben.
      Kürzlich habe ich das Ledger-System eines ziemlich alten Startups beraten und war entsetzt zu sehen, wie es aussieht, wenn Engineers ohne Finanz- oder Rechnungswesen-Hintergrund ein Buchhaltungssystem bauen.
      Man muss keinen magischen Buchhalter-und-Engineer in einer Person finden. Es reicht schon, im Designprozess einen echten Buchhalter neben das Engineering-Team zu setzen. Nachdem wir das Redesign insgesamt entworfen hatten, ließ ich es von einem befreundeten CPA vollständig prüfen; er fand in einigen Szenarien Lücken, aber im Großen und Ganzen war es in Ordnung.
      Geld ist ein schwieriges Engineering-Problem, weil mit Geld all die menschlichen Absonderlichkeiten einhergehen, die es umgeben.
    • Genau. Ein Ledger ist Domänenwissen. Alles andere, einschließlich Optimierung für hohe Last, muss darauf aufbauen.
    • In manchen Gruppen gibt es die nervige Tendenz zu glauben, Technologie könne jedes Problem lösen. Weil Innovation über alles gestellt wird, hält man Experten auf Abstand.

  • Es bestätigt erneut, wie wichtig Domänenwissen in der Engineering-Führung ist. Wenn man bei einem Finanzunternehmen arbeitet, muss man Finanzen in gewissem Maß verstehen, um die richtigen technischen Entscheidungen und Abwägungen zu treffen; für Journalismus oder Handel gilt dasselbe.
    Erfolgreiche Organisationen, in denen ich gearbeitet habe, haben in Interviews für Technikteams immer domänenspezifische nichttechnische Fragen gestellt. Umgekehrt sind einige technisch sehr starke Teams ins Straucheln geraten, weil ihnen Domänenverständnis fehlte.

    • Ich bin Software Engineer und zugleich CPA, habe also Domänenwissen. Aber ich weiß nicht, wie ich Arbeit finde, bei der ich das anwenden kann.
      Überall scheint man viel lieber jemanden zu wollen, der zwar gar kein Domänenwissen hat, aber doppelt so viele Jahre Software-Engineering-Erfahrung, als jemanden wie mich mit Buchhaltungserfahrung und vergleichsweise kurzer Software-Engineering-Laufbahn. Ich frage mich, ob es eine Möglichkeit gibt, das effektiv zu nutzen.
    • Ich stimme der Stoßrichtung zu, aber es hilft, solche domänenspezifischen Fragen einfach als technische Fragen aus einem anderen technischen Bereich zu betrachten.
      Finanzwesen ist technisch, Maschinenbau ist technisch, und auch Sportmanagement oder Soziologie haben große technische Anteile. Wenn man breiter darauf schaut, was technische Kompetenz ist, entsteht die nötige Demut, um über verschiedene Domänen hinweg zusammenzuarbeiten.
    • Seit ich bei einer Versicherung arbeite, habe ich gemerkt, dass es viel schwieriger ist, die Versicherungsbranche zu verstehen als die Codebase. Wenn die Codebase seltsam funktioniert, kann man sie wenigstens mit dem Debugger nachvollziehen.
    • Da bin ich mir nicht so sicher. Ich habe immer verstanden, dass es die Aufgabe des Produktmanagers ist, das gesamte Domänenwissen zu haben.
      Es ist Aufgabe des PM, gemeinsam mit Engineering zu prüfen, ob die Anforderungen richtig sind und ob das gebaute Produkt diese Anforderungen erfüllt. In einer agilen Umgebung finden solche Gespräche und Validierungen in jedem Sprint statt, daher ist es schwer vorstellbar, dass etwas allzu lange ungefiltert durchrutscht.
      Wenn es keinen PM gibt, braucht das Engineering-Team tiefes Domänenwissen; andernfalls ist das aber nicht die Verantwortung von Engineering, sondern der Produktorganisation.

  • Um eine alte Geschichte zu erzählen: Ich habe nie ein System für doppelte Buchführung gebaut, aber vor Jahrzehnten habe ich in einem Internet-/Telekommunikations-Startup, dessen Umsatz auf achtstellige Beträge wuchs, ein Abrechnungssystem gebaut.
    Als junger Entwickler wusste ich es nicht besser und bekam zufällig gleich am ersten Tag die Abrechnungslogik zu bauen; zum Guten oder Schlechten baute ich sie an zwei Stellen im System. Eine war die Abrechnungs-Webseite für Verbraucher, die andere ein separater Backend-Prozess, der Rechnungen erstellte und Kreditkartenzahlungen ausführte.
    Beide synchron zu halten, war erstaunlich schwierig. Wir verbrannten Kapital und iterierten ständig, um Marktresonanz zu finden; ständig kamen neue Produkte und Dienste, neue Rabatt- und Preismodelle, nutzungsbasierte Abrechnung, monatliche Abrechnung, die ersten X Vorgänge kostenlos, Hauptzahler/Unterkonten bei Firmenkonten, vom Nutzer festgelegte Kostenstellen sowie Steuerzuordnung und Cent-genaue Verteilung auf diese Kostenstellen hinzu. Jedes Mal entstanden neue Falten und Ausnahmen, und die Zahlen in den beiden Ansichten/Verfahren stimmten nicht überein.
    Da ich für die Abrechnung verantwortlich war, verbrachte ich jeden Monat mehrere Tage damit, alle Rechnungen von Hand durchzugehen und als letzte Kontrolle vor Kreditkartenbelastungen und dem Versand von Papierrechnungen zu prüfen, ob die Zahlen stimmten. Immer oder zumindest häufig fand ich ein neues Problem, das einen einzelnen oder wenige Kunden betraf, und korrigierte den Code vor der eigentlichen Abrechnung. Mir war immer unwohl dabei, alles loszulassen, ohne es von Hand noch einmal zu prüfen.
    Ich überlegte, die Abrechnungslogik an eine Stelle zu refaktorisieren, um Inkonsistenzen und manuelle Gegenprüfungen zu beseitigen. Nach langem Nachdenken merkte ich jedoch, dass mir eine einzelne Codebase unangenehm war und die zwei Codebases mir im Gegenteil halfen, Fehler zu finden. Danach machte ich die automatische Ausführung und Gegenprüfung zwischen den beiden Implementierungen nach und nach einfacher.
    Der Abrechnungscode war zu schmutzig, um stolz darauf zu sein, aber auf die Genauigkeit der Abrechnung, das Ausbleiben von Beschwerden und die über Jahre vermiedenen haarsträubenden Fehler war ich sehr stolz. Wegen der Komplexität, die ich meinen Nachfolgern hinterlassen habe, habe ich ein wenig Schuldgefühle, aber auch heute bereue ich es nicht wirklich.
    Nach dieser Erfahrung habe ich die Motivation hinter doppelter Buchführung immer gut verstanden. Um meine eigenen Fehler davon abzuhalten, Kunden zu schaden, hatte ich auf schlampige Weise Abrechnungscode mit doppelter Logik neu erfunden.

    • Bei Abrechnung oder allem, was mit Geld zu tun hat, ist es viel zu leicht, falschzuliegen.
      Ein Datenteam, das ich in einer früheren Firma übernahm, hatte die unglückliche Angewohnheit, Geld zu „verlieren“. Es war nicht so, dass echtes Geld auf dem Weg woandershin verschwand; vielmehr verschwanden Datensätze, auf deren Grundlage Kunden hätten belastet werden müssen.
      Wenn wir nicht gerade Umsatz verloren, stellten wir doppelt in Rechnung, und so ging es immer weiter. Es dauerte 3 Jahre harter Arbeit, das Vertrauen der Geschäftsleitung zurückzugewinnen.
    • Nicht böse gemeint, aber das klingt nach einem Albtraum. Gleichzeitig ist es wirklich beeindruckend, dass trotz der Komplexität des Systems Korrektheit erreicht wurde. Darauf kannst du stolz sein.
    • Das ist N-version programming sehr ähnlich.

  • Gab es nicht einmal Tests? Wenn bei jeder Transaktion Geld verloren geht – bis hin zu dem Beispiel: „Bei jedem Kauf über 5 Dollar blieben im Transaktionslog 4,98 Dollar übrig“ –, dann ist das Problem viel größer als nur fehlende doppelte Buchführung.
    Wer baut so ein Finanzsystem und hält das für normal? Die Vergütung ist auch ein Problem, aber vor so einem Service sollte man so schnell wie möglich weglaufen.

    • Genau diese Leute haben das getan. Sie haben selbst gesagt: „Wir hätten es richtig bauen können, haben es aber nicht.“ Es war kein Unfall, sondern eine Entscheidung.
      Sie machten Witze über „tanzende Cents“ und taten es, weil sie wussten, dass sie keine nennenswerten Konsequenzen tragen mussten. Sie bewegten sich schnell, machten etwas kaputt – etwas, das mit Geld zu tun hatte – und lachten es weg.
      Jetzt wollen sie anderen etwas beibringen, als hätten sie moralische und technische Autorität, gerade weil sie diese Entscheidungen absichtlich getroffen haben. Das ist erstaunlich arrogantes Geschwätz aus der Startup-VC-Kultur.
    • Ich verstehe immer noch nicht, wie das Geld verloren ging. Doppelte Buchführung hätte bei der Diagnose geholfen, aber wie ist es tatsächlich verschwunden?
    • Das war auch mein Gedanke. Ein Ledger hat viele Vorteile, aber es behebt das Problem der tanzenden Cents nicht. Dann stehen eben falsche Zahlen im Ledger.
      Natürlich kann es Hinweise liefern, um den Bug zu finden, aber grundlegende Tests zu schreiben hätte das ebenso getan.
    • Ein gutes Designprinzip ist so viel wert wie 1000 Tests.
    • Wie beurteilt man, ob diese Geschichte wahr ist?

  • Ich verstehe nicht, warum der Autor die Maxime „make it work, make it right, make it fast“ negativ heranzieht. Vermutlich missversteht er, wo „make it fast“ hingehört.
    „Make it right“ ist der zweite Schritt, und dort sollte die Arbeit stehen bleiben, bevor es korrekt funktioniert. Das System muss solide funktionieren. „Make it fast“, also Optimierung, beginnt erst, nachdem Korrektheit und Solidität vollständig gelöst sind.
    Das hat nichts mit Liefergeschwindigkeit oder schnellem Arbeiten zu tun, sondern bedeutet, Optimierung auf den letzten Schritt zu verschieben.
    Wenn der Autor allerdings sagen wollte, dass etwas zwar grob „funktioniert“, aber so weit von „richtig“ entfernt sein kann, dass man es später nicht mehr zurückdrehen und reparieren kann, und dass man es gerade bei solchen Dingen von Anfang an „richtig“ bauen muss, noch bevor es überhaupt gerade so funktioniert, dann verstehe ich das.

    • Ich denke, der letzte Satz trifft es. Der Autor scheint zu sagen, dass man bei Zahlungssystemen nicht erst etwas zum Laufen bringen und es später richtig machen kann.
      Ich sehe das genauso und war einmal an der Prüfung von Fintech-Systemen beteiligt. Die Prüfer mussten vor der Freigabe der Bücher alles in Excel-Tabellen herunterladen und die Zahlen abstimmen. Das kostete viel Zeit und Geld, und ich vermute, dass es drei Jahre später bei einem Liquiditätsereignis mindestens etwa 0,1 Unicorn Unterschied gemacht hat.
    • Ich denke, der Autor hat die falsche Maxime gewählt.
      In schnell arbeitenden Startups bringt man so schnell wie möglich faktisch ein MVP heraus. Weil man Kundenbasis, Finanzen usw. aufbauen muss, bleibt man in der Phase „make it work“ stecken.
      Eine bessere Maxime wäre Facebooks „move fast and break things“ gewesen. Das funktioniert allerdings nur, wenn man es später reparieren kann. Wenn man zum Beispiel Flugzeuge baut, würde man so nicht vorgehen.
    • Es hieß, das Engineering-Team habe diese Maxime befolgt, und darin ist „make it right“ enthalten. Aber das haben sie nicht getan. Sie haben nicht einmal versucht herauszufinden, was sie über Fintech nicht wissen, bevor sie das Produkt bauten.
      In diesem Kontext wirkt das im ersten Satz erwähnte Missverständnis am plausibelsten. Direkt danach geht es nämlich um den Zeitdruck, unter dem Startups stehen.

  • Die meisten Kommentare hier wiederholen genau das, was der Artikel kritisiert. Ich sehe unzählige lange Diskussionen zur Verteidigung der einfachen Buchführung.
    Einfache Buchführung mag leichter und stärker verallgemeinert sein, aber manchmal ist es eine gute Idee, einfach Systemen und Abstraktionen zu folgen, die sich über Jahrhunderte entwickelt haben.
    Wenn man nicht zwingend etwas anderes braucht, ist doppelte Buchführung die bessere Wahl. Für den Programmiererinstinkt mag sich das unangenehm anfühlen, aber in dem Moment, in dem man einen echten Buchhalter holen muss, um Unstimmigkeiten zu bereinigen, wird man dankbar dafür sein.
    Kennt jemand in diesem Zusammenhang gute Materialien für Programmierer in Payments oder angrenzenden Bereichen? So etwas wie „Buchhaltung für Programmierer“?

  • Wenn jemand sagt, er verwende ein Datenbanksystem, bei dem bei jeder zehnten Transaktion 1 % der Daten verschwindet – könnte man solche Ratschläge aus einem Engineering-Blog dann ernst nehmen? Dieser Text fühlt sich weniger wie eine Einführung in ein Konzept an, sondern eher wie eine ruhig verpackte Werbeanzeige für eine bestimmte Person oder Gruppe.

  • Wenn man sehen will, welche Folgen eine derart nachlässige Haltung gegenüber Software, die Geld bewegt, für echte Menschen haben kann, sollte man sich den Post-Office-Skandal ansehen.
    https://en.wikipedia.org/wiki/British_Post_Office_scandal
    Alles, was Geld bewegt, muss mit größtmöglicher Ernsthaftigkeit behandelt werden, und man sollte so viele historische Fehlschläge wie möglich kennen.