I once did some consulting for a very prominent bond fund manager. His main tool was an excel spreadsheet which was the most godawful mess you can imagine. Dozens of separate pages with tens to hundreds of thousands of cells each. I ended up writing some VB code to dump all the formulas into a text file where I could parse them and do some automated analysis (using Common Lisp). It turned out that the spreadsheet was in fact as much of a train wreck as it appeared to be. Most of it turned out to be dead code, i.e. >50% (I don't remember the exact number) of the cells did not figure into the final result.

But the worst part was that there turned out to be a single input that completely dominated the final result, and that input was a "gut feel" that the fund manager had about which way the market was going to move. So after all that calculation, the upshot was that the fund investment decisions were being made based on this individual's intuitions, and the entire spreadsheet was just window dressing. Ironically, the audience for the window dressing was the fund manager and his team because the spread sheet was considered proprietary, a closely guarded secret. That's the reason I'm not revealing the name of the manager. I'm probably still bound by the terms of the NDA.

That was the moment that I realized that much, if not most, of Wall Street is a colossal scam.

Not so much a scam per se, but a colossal example of correlation does not equal causation. At least for the old world traders. Newer hedge funds are definitely churning out returns that indicate something proprietary is going on. But anyone bragging about a gain of +2% over the market is kidding them selves.

Any complicated spreadsheet might be a bug ridden mess, but at least it's one the finance guys understand and can augment themselves.

Alternatively they could wait for in-house IT to take a few years and millions of pounds (add going running over schedule and budget, too) to produce a bug ridden mess that misses.

Programmers tend to look at shitty programs and imagine better ways that it could have been done... In practice the competitor to a shitty program is not a better program, but no program at all. Even shitty software can still make the world a better place, and the preponderance of half-assed bug-ridden brain-dead garbage software should be seen as a good thing.

thank you. I have the feeling that many participants in this overall chauvinistic discussion here see themselves as artists that always produce perfect outcomes, ignoring the history and productivity of the software actually in place.

And on this positive note, you might want to have a look at efforts to make spreadsheets better: https://www.microsoft.com/en-us/research/publication/improvi...

Hell, we even look at good programs and imagine we could have done them better.

>but at least it's one the finance guys understand and can augment themselves.

And more importantly it enables the "money people" and the "1s and 0s people" to work together throughout the software life-cycle. When the people who input the data understand what's going in and the people who read the output know what should come out the black box in the middle is a lot easier to create and maintain.

Trading desks and other tech savy groups overuse spreadsheets so that can minimize their interactions with a bank's underwhelming IT department.

Of course, the above is a generalization, but I stand by the assertion most tech savy bank workers try to interface with Bank IT as little as possible.