Henrico Dolfing

What became universal in the industry is an item on the checklist saying that you have safety checks to prevent this. How seriously that item is taken, i suspect, varies quite a bit.

In my experience, you aim for multiple extremely simple checks, with minimal logic and minimal calculation, so you can have confidence they won't have surprising behaviour in an unusual situation like this.

The classic example is an order count limit - initialise a counter to some value at startup, and every time the machine sends an order, try to decrement it. When it hits zero, it can't send orders any more. Just throw an exception or return early or something. You display the value of the counter to human operators, and give them a button which resets it to the initial value. In normal operation, you are sending orders at a steady trickle, and humans will have to press the button every now and then. If something goes insanely wrong, as here, the counter will run down quickly, and then the humans hopefully won't push the button, because something is obviously wrong. It's a very crude safety, but it is a simple one.

Another is a limit on message rate. You could use a token bucket filter. Does not affect normal operation, but stops a machine which is spraying out excessive orders. You could have it so that if the bucket runs out, it turns off until a human explicitly turns it back on.

You have limits on net position too, to stop you running up huge positions in anything, but those are…

[1] suggests that part of the problem is that Lidl's business processes were non-standard, and Lidl decided, rather than change their processes to match what SAP's solution supported, to instead customise SAP's solution to support their non-standard processes – and that was the point at which the project came undone, the SAP customisations couldn't scale to high turnover (but surely vanilla/uncustomised SAP Retail would not have had this problem)

Lidl's non-standard processes may well be a big part of their business success. But maybe that was a sign they shouldn't have gone with an off-the-shelf solution like SAP, and should have stuck with their legacy in-house system, or tried to build a custom next generation in-house system. And their experience isn't necessarily transferable to another business whose processes might be more standard, or who might have more flexibility to alter their processes to meet the needs of an off-the-shelf solution. And if they'd gone for some other off-the-shelf solution instead of SAP (such as Oracle or Infor), they might have had just as many problems – the more customisation heavy an ERP implementation project is, the greater the risk of failure.

[1] https://www.henricodolfing.com/2020/05/case-study-lidl-sap-debacle.html

> Someone at Thoughtworks sold Dominion Energy on the idea that Thoughtworks... if things go well, they will get follow-on business and maybe even a whitepaper.

...

> Market pressures don’t apply to internal teams

Market forces are constantly applied against internal IT teams, particularly in non-tech companies. The market force is replacing them with consultants. Sometimes they will make those employees train their own replacements[1][2].

Or that there are consultants that can't be fired. The project is over schedule, but too much sunk cost to replace them and no internal devs. A $6M project becomes a $1.25 billion project and fails in slow motion over a decade.[3]

Anyway, my point is that it's not as simple as "internal is always safe, consulting is always tougher".

[1] - https://www.nytimes.com/2015/06/04/us/last-task-after-layoff-at-disney-train-foreign-replacements.html

[2] - https://www.mercurynews.com/2016/11/03/after-pink-slips-ucsf-tech-workers-train-their-foreign-replacements/

[3] - https://www.henricodolfing.com/2019/12/project-failure-case-study-queensland-health.html

Imagine if that was Meta that had over 1B users with their messenger desktop app update functionality that did just that. The loss would be in the hundreds of millions.

> But agree that senior gatekeepers should know by heart some places where review needs to be extra careful. Like security pitfalls, exponential fallback of error handling, and yeah, probably this.

The lesson here is much better use of automated tests (The app likely has no tests at all) and proper use of basic testing principles like TDD would prevent such junior-level embarrassing bugs creeping up in production paid software.

That is the difference between a $100 problem vs a $200M problem.

See the case of Knight Capital [0] who lost $460M, due to a horrific deploy.

[0] https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html

Also, what's your approach to risk management?

For example:

1. Do you have anything that limits the size of a single trade or position?

2. How do you measure and manage overall volatility/risk/VAR to your portfolio?

3. What kind of safeguards do you have to avoid catastrophic bugs? (For reference, see Knight capital and how a single bug brought down the entire company: https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html) Given how fast your system trades, I imagine it must be difficult to visually spot these errors. (You did mention paper trading, but I wonder if you have anything else you want to mention)

Thanks so much for sharing your knowledge publicly. It's very much appreciated!

> And avoid some code bug causing them to lose all their money

Well, everything has a non 0 chance but you can code certain conditions that have to be met before an order goes through.

IMO, you would have to have significant capital to even end up in a situation where a bug causes lots of loss.

Here is an example of something you might be thinking of.

https://www.henricodolfing.com/2019/06/project-failure-case-study-knight-capital.html

> Not get lose all their money to some company's API fees

It's not too bad these days. A lot of brokers offer "zero-fees" which really just means you only have to pay the SEC ones which aren't too bad.