5 ms·

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 prod

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" ;)

nurettin 9y ago
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".
posterboy 9y ago
It's a fact that you can't ever have enough tests, because, for one, the tests are not tested.
- eru 9y ago
  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.
- Smurfix 9y ago
  Of course the tests are tested – by the code they're covering, which is also covered by other tests.
incompatible 9y ago
I heard some banks still did crazy things like calculating mortgage payments with spreadsheets.
- osullivj 9y ago
  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.
  - eru 9y ago
    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.
    - dsfyu404ed 9y ago
      >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.
    - lmkg 9y ago
      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 9y ago
        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.
einrealist 9y ago
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.
usr1106 9y ago
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 9y ago
  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.

nurettin 9y ago

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

posterboy 9y ago

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

eru 9y ago
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.
Smurfix 9y ago
Of course the tests are tested – by the code they're covering, which is also covered by other tests.

incompatible 9y ago

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

osullivj 9y ago
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.
- eru 9y ago
  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.
  - dsfyu404ed 9y ago
    >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.
  - lmkg 9y ago
    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 9y ago
      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.

einrealist 9y ago

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.

usr1106 9y ago

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 9y ago
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.