[Horusiath]

This is not only a DB specific, a whole banking industry works like that. Systems that have <10 years are considered new ones. To keep things working, just produce 5x more services created solely to move data from one place to another. No focus on programming discipline or sense of purpose and constant fear to change anything, because that could break things and we have not enough tests or monitoring infrastructure to even detect that. But in finances, IT is not on a focus. After all, we're just a "cost center" ;)

[einrealist]

I can underwrite this. I am currently working for a(nother) bank. And I want to add that a lot of the legacy systems, procedures and thought processes stem from the misinterpretation of regulations.

When a bank gets a new regulation on their table, they tend to create a department that compartmentalizes the subject within the organisation. That's how we get the exact opposite of what the Agile mindset is. And that's also how we get organisations where nobody wants to work in, except if the pay or day rates are high enough to excuse any suffering. And that's how bad, bloated software is created.

[nurettin]

This is my exact experience while integrating with ERP systems in at least four global firms. Except I'd change the phrase "not enough tests or monitoring" to "no tests or monitoring except the ones I wrote".

[usr1106]

This is not banking specific, the whole SW industry works like that. I have worked over 20 years in a couple of companies, where SW was an essential part of our products. Yet the quality has never been good, it's a bloat of solving similar problems again and again. Architecture is a mess, even if there are n architects who can present nice diagrams. (I have seen n=1 and n>30, but the fundamental problem is the same)

[usr1106]

To extend my thoughts a bit.

Yes, I believe that some sectors might be worse than others. There are metrics and tools provided by the Software Engineering discipline to measure quality of architecture or code. However, they have remained mostly academic. There is no standard metric, which is widely accepted to be useful. And even if some rare(?) company might systematically measure their code base, they don't put the results in the their home page and not even in the contract with their customer.

As long as that does not change, it's just more or less educated feeling where the situation might be better or worse than elsewhere.

[incompatible]

I heard some banks still did crazy things like calculating mortgage payments with spreadsheets.

[osullivj]

Spreadsheets are heavily used in all financial sectors. Personally I've connected many trader developed pricing spreadsheets to etrading systems at investments banks. Last year I was contracting for a large UK mortgage lender who used spreadsheets for all their product dev & spec. Spreadsheets enable bankers to move quicker than bespoke or vendor supplied solutions, hence their enduring popularity.

[lisper]

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.

[beepboopbeep]

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.

[eru]

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.

[lmkg]

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.

[bald]

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.

[eru]

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...

[eru]

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

[dsfyu404ed]

>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.

[jgalt212]

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.

[posterboy]

It's a fact that you can't ever have enough tests, because, for one, the tests are not tested.

[Smurfix]

Of course the tests are tested – by the code they're covering, which is also covered by other tests.

[eru]

That's funny in practice. But does not have to be a problem in principle.

There are ways to test your tests (in a way that does not lead to an infinite regress), and alternatively you can also prove your tests correct; or just use plain old code review.