“Oops! Trader mistakenly spends $251 million” - An…
October 12th, 2006 by satish“Oops! Trader mistakenly spends $251 million” - Another Business Rules Example
“TAIPEI, Taiwan - A Taiwan stock trader mistakenly bought $251 million worth of shares with a mis-stroke of her computer, meaning her company is looking at a paper loss of more than $12 million and she is looking for a new job.
The trader with Fubon Securities made a typo while filling in a small order from Merrill Lynch on Monday, creating confusion when many small firms inexplicably surged past the 7 percent trading limit.
“Something like this is difficult to explain to superiors,” a Fubon executive said on Tuesday.”
Read more at http://msnbc.msn.com/id/8382753/?GT1=6657
… my guestimate is that the poor soul, just added a couple of extra zeros there. well dont want to play the blame game, but really….
Bad testing? Bad User Acceptance Testing? I really dont know. My take? Form validation rules
-
NO TRADE, SHALL BREACH THIS:
If
The trade amount is greater than 25 million$
Then
……
(Do whatever, dont execute the trade…).
The result: some stocks inexplicably rose 7% that one day. (Apart from the obvious losses to the company).
In hindsight perhaps it is easy to talk about this. Sitting in front of my comp, sipping my coffee and writing this blog its easy to see. Visualization before the event would have been really tough. I empathize with the IT there and more so with the trader who lost his job. The article goes on to say that the trader was not familiar with the new computer system, but give the poor guy a break!
One could argue that its poor testing. But think of it, if within the process we have a “validate trade” ruleset (or group of business rules) along with perhaps a decision tree or whatever (some form of sequential logic really - call it workflow rules whatever or just plain procedural code) and this was visible to a business analyst, there was perhaps a much better chance of identifying it.
Better yet if the business rules were unit tested - it would have been flagged. It beats me, if for code the idea is to unit test, do integration testing and then user acceptance - why dont we do that for business rules - isolated independent business rules. Thats what the business rules approach will bring to the table - a discipline that could avoid errors.
So when one talks of “costs of correction” you know what it means - it is precisely these avoided costs that are de-risked. For critical form data, least one can do (whether you are going in for a Business Rules approach or not): Externalize the business rules-make sure the execution is visible. I would say externalize the rules (jar file, dll whatever) - just that act of having it externalized and tiered will help.
Am i going overboard and suggesting that Business Rules approach would solve everything? Perhaps even without a BR approach, good disciplined programmers would have caught it or perhaps users …, the point is you need the right tools for the right job.
We helped a leading investment bank in “Trade Lifecycle Management” a few years back. At first i couldnt believe it that the folks there were investing that kind of money in the project (and to think of it most rules there were validation rules).
My company’s(YASU Techologies) product architect wrote an interesting white paper on testing business rules. You can download a copy at:
“How Conventional Testing Methods are not equipped to handle Business Rules Implementations”