Hacker News Reader

Comment by Aeolun | Hacker News Reader

No tests either? If you lose track of enough money every transaction that you can make an example of 'Every $5 purchased resulted in $4.98 in the transaction log' I think your problem is far, far bigger than not having double entry bookkeeping.

Who builds a financial system like that an considers it normal? The compensation is one thing, but you'd flee a service like that with all possible haste.

View on HN

These guys. They said it themselves. “We could have built it right, but we didn’t.” They chose not to. It was not an accident. They made jokes about “dancing cents”. They did these things because there would never be meaningful consequences for doing them, and they knew it. They move fast, they broke things - money things - and they laughed about it. And now they’re lecturing people as if having willfully made these decisions gives them both moral and technical authority. This is magnificently pompous, startup VC culture nonsense.

Sounds like they refunded anything that went wrong so it's not really as bad as you make it sound.

Refunds limit damages in a lawsuit, but don’t prevent legal issues.

Especially important when explicitly saying you’ve done these things.

critically, only when customers reached out. which means tons of people that weren't eagle eyed got defrauded.

No, they refunded when a customer complained. Any customer that didn't notice or didn't complain didn't get what was rightfully theirs. That should be criminal, if it isn't.

I still didn't understand how they lost the money. Yes, double entry bookkeeping might have helped diagnose it, but how were they losing it?

Yeah that was my thought as well. Ledgers have tons of benefits but they’re not going to fix your dancing cents problem. You’re going to have bad number on the ledger.

Sure, maybe that points you to the bugs, but so would writing basic tests.

A ledger where you insist that every entry touches exactly two accounts, in a business where transactions regularly involve various types of fees, could easily misplace or misattribute a few cents here and there.

This type of business can also have fun dealing with accruals. One can easily do a bunch of transactions, have them settle, and then get an invoice for the associated fees at variable time in the future.

> where you insist that every entry touches exactly two accounts

A ledger is where every transaction balances to 0. It can involve multiple accounts, but the sum of all transfers between all accounts in a single transaction must sum to 0. This is the property of double entry that actually matters.

Maybe I'm being naive, but this seems to be not too difficult... You have a general ledger in which the invariant that it always balances is properly enforced. The hard bit is scaling and performance. There are policies around fractional transactions, but you should never get mismatched entries.

I think the trick is to store the movement not the balances. You may cache the balance, but what matters is the journal of money moving from one account to another.

Exactly. Any proper ledger is a transaction log. Balances and turnovers are calculated, not stored. I've seen a lot of attempts to 'cache balances', and this was always the point where anything could go wrong.

A good design principle is worth a 1000 tests.

How do you figure the story is true?

Reply on news.ycombinator.com