← Back to context

Comment by neuroelectron

1 year ago

I don't know what the fuck I just read here. I've worked on ledgers for years with massive codebases with millions of loc and I've never seen an error of "a few cents". Feels like I just read a alibi. Don't develop financial software from scratch.

That was my reaction too.

It was like reading an engineering team saying their attempt to design a new lightweight mountain bike failed. It turned out saving weight by omitting brakes wasn't a good idea, and their attempt to fix it by riding beside each bike and manually slowing it down wasn't too popular either. Then they have the hubris to follow that up with, "you can avoid the same mistakes by reading what we have to say on bicycle design".

The lessons they can take away have very little to do with engineering or FinTech. I'd file it under doing a bit of research before committing to any major task. Basic accounting principles are centuries old now. They could have learnt about them by buying a high school text book, reading it cover to cover and use doing the exercises. It would have taken them less than a week.

Admittedly that only gives you the "how", not the "why". You realise much, much later that the engineering equivalent of double entry accounting is two systems design by different teams that are constantly comparing their outputs. By the time you've figured that out, it's caught so many errors you realise "holy shit, these systems are really easy to screw up, and are under constant attack by malicious actors".

There is a hidden trap at every step - floating point being imprecise, currency rounding not being reversible, tax calculations being one way, ACID being a hard requirement. I'm being this mob screwed up tax calculations. Floating point throwing out 1 in 100 million transactions was one of the joys they never got to experience.

The lesson here is not to never develop from scratch. In fact it may be faster and safer to do so than to vet all of the open source junk that modern ByteByteGo-system-designers think they need. TigerBeetle and Jepsen-proof-engineering are paths to dig down here, along with basic knowledge of computer number storage.

The lesson for me here is that there is no substitute for knowing or caring about what you're doing. Dancing cents don't happen when eng cared about correctness in the first place. I feel like I just read a college freshman explaining how there's no possible way they could have passed their first exam. Better yet he's here to sell us on his thought leadership without ever explaining why he failed the first exam.

I read the intro and decided I wouldn't learn much from someone willing and eager to admit he eats paint chips.

I've seen it, sighed, fixed it, and ensured the necessary accounting adjustments assigned the loss to the business instead of the customer. Seems that last step, which is the most important one, wasn't followed here, which is the real shame.

  • To be fair, I have seen it before because of a modification I did to the code base. It was when I first started working with it so I didn't really understand how to correctly implement extensions. But still, i was able to see the error in the ledger and connected to my change.

I had the same thought. I mean, were they actually using ordinary floating-point numbers to represent amounts in their ledger? This sets off so many alarm bells.