It is not about confidence. It is about ownership and being a good engineer. A good engineer would have cared about the code base and ensured that a test would fail, a use case would be linked to that failure, and someone would see that they have now violated a regulation.

Then if the regulation changed, someone would grep through the use cases, and see what behavior is occuring/ how to modify the code base to cope with the change in regulations (this occurs a lot). Of course most finance firms don't do this and actually violate regulations all the time. There is literally a gold mine for the SEC/FINRA to go after, but the government is fairly incompetent at mining through the data and holding companies accountable. The reason being that they don't pay enough to hire the talent that would uncover the violations.

Real engineers are like true Scotsmen, because you can never have enough process.

In this case, of course tests really do prove the absence of bugs rather than just (not) proving their presence.

I really don't like the whole "unit tests lets you not worry about breaking things" view. That's not confidence, it's overconfidence. And it doesn't even mostly work for things where "correct" is more fuzzy than "eventually produces this exact output".

It is confidence. It is the right tool for the job.

What would you propose as an alternative?

I'd be surprised if they didn't make postmortem changes to prevent such incidents in the future. Your posts in this thread imply that no mistake should ever happen, but let's be real - mistakes will always happen, the key is to do proper postmortem analysis and learn from them (and obviously prevent recurrences).

Some mistakes, yes. But this was a case of such a basic and clear cut use case that should have been tested.

My understanding is that companies such as this rely purely on manual testing. Thus it is easy for things to slip through the cracks. Usually they never get hit by penalties or get caught so the pressure to do better is not there.

Yeah, well, fkups happen, you just gotta make sure you are making more money than you lose in those incidents.

Or you just write a test that checks to make sure you don't screw up.

If you're designing a new airliner then yeah, you can't screw up, and you end up taking years to deploy.

In the HFT world, you may have only days, or sometimes hours, to deploy. Yes you still write tests, and a bazillion safety checks when you deploy, but if you manage your risk down to zero then this is definitely not the most profitable way to go.