3 ms·

Developing bank software is just different. There can be no rapid iteration, because every bug is disastrous. As a result, software evolves at a glacial pace. I

by nzmsv 17y ago

Developing bank software is just different. There can be no rapid iteration, because every bug is disastrous. As a result, software evolves at a glacial pace. I'd think that the answer to the question about what technologies you need to know to work on financial systems would include COBOL, possibly before Java.

ivenkys 17y ago
I disagree with this. Again, it depends on the area you are working in - software does not evolve glacially on a Trading Platform. Its in fact quite the opposite. Anytime you are directly working with Traders or Front-Office Quants this is simply not true.
- dannywoodz 17y ago
  Agreed. The system I worked on had scheduled releases every two weeks, with a smattering of emergency releases in between. In some cases, simply being able to reliably price a given trade put you ahead of the competition, particularly in the exotics space, and could make or break a deal. The big problem with a system like this is that, when faced with the do-it-right/do-it-fast dilemma, do-it-fast is what wins. Too much of this can yield a brittle system as hacks pile on top of each other, so it helps to be able to slide 'proper' fixes into the trailing dev/test cycles. A flexible platform/language helps, too.
swombat 17y ago
There can be no rapid iteration, because every bug is disastrous. As a result, software evolves at a glacial pace. Having spent 4 years building software at large investment banks, both on the coding side and on the managing side, I can affirm without hesitation that the glacial pace has very little effect on the (high) incidence of bugs. The quality of software produced in banks is generally appalling. The reason it's slow is because the complexity is sometimes very high, the volumes of data to process are often very large, and the communications overheads between bank departments are just insane. Quality (or lack thereof) has nothing to do with it.
potatolicious 17y ago
"There can be no rapid iteration, because every bug is disastrous" I work for a company that handles a lot of commerce, and bugs can be disastrous, and stakes are high - we still iterate. Sure, we're not pushing new versions live every single night, but our cycles are still relatively quick. I think the "there's too much on the line if a mistake happens" line of thinking is a cop-out. There are ways to mitigate this risk, safeguards and methodologies.
ig1 17y ago
Plenty of banks use agile development methodology.
- gaius 17y ago
  Plenty of banks also haven't touched code that's been running just fine for the last 30 years. You just upgrade the mainframe under it...
  - AndrewDucker 17y ago
    Plenty of banks have both. That's the advantage of n-tier systems. You keep your ancient databases, stick some business rules on top in Java and then talk to them from a bunch of clients that you can tweak as much as you like without worrying that you're going to break the important stuff.
- StrawberryFrog 17y ago
  Plenty of banks want to use agile, because they've heard it's cool, is said to deliver more better software faster, and is attractive to good coder job candidates. How far they are actually getting with it is another question.
StrawberryFrog 17y ago
er, getting bugs out early is a major argument in favour of test-first agile iterative methods. You don't ship every iteration, but give it to the testing team. Would you get better results from giving your testing team a new release once per year?
- omouse 17y ago
  Getting bugs out early is actually a major argument in favour of thinking before banging out code. Tests after the fact don't do enough to lower the number of bugs there are.
  - StrawberryFrog 17y ago
    Oh, where to start with this one... * No agile method stops you from doing a bit of design thinking before you code, when it is needed. Agile is against Big Design Up Front as a matter of course because it so often fails to be good design, or appropriate for what the business ends up wanting. * Lots of automated tests done while coding that allows you to think sooner and better about your code. decreasing the need for big design up front, and better suiting the design to what you actually find your needs to be. Not thinking beforehand is a risk for sure, but producing a big, inflexible, unsuitable design is another risk. I've seen it, you may have too. Thinking without testing the thoughts in code is bad too. * "Tests after the fact" refers to QA. Agile also emphasises unit tests before and during the fact. "Tests after the fact don't do enough to lower the number of bugs" is something that any agilist would agree with, but would recognise as an argument for agile. * Rapid release to QA allows actual users/sysops to see where you're going much earlier, hence mitigating major risk of building the wrong thing/right thing but not scalable/performant enough/etc.

by nzmsv 17y ago

ivenkys 17y ago

I disagree with this. Again, it depends on the area you are working in - software does not evolve glacially on a Trading Platform. Its in fact quite the opposite. Anytime you are directly working with Traders or Front-Office Quants this is simply not true.

dannywoodz 17y ago
Agreed. The system I worked on had scheduled releases every two weeks, with a smattering of emergency releases in between. In some cases, simply being able to reliably price a given trade put you ahead of the competition, particularly in the exotics space, and could make or break a deal. The big problem with a system like this is that, when faced with the do-it-right/do-it-fast dilemma, do-it-fast is what wins. Too much of this can yield a brittle system as hacks pile on top of each other, so it helps to be able to slide 'proper' fixes into the trailing dev/test cycles. A flexible platform/language helps, too.

swombat 17y ago

There can be no rapid iteration, because every bug is disastrous. As a result, software evolves at a glacial pace. Having spent 4 years building software at large investment banks, both on the coding side and on the managing side, I can affirm without hesitation that the glacial pace has very little effect on the (high) incidence of bugs. The quality of software produced in banks is generally appalling. The reason it's slow is because the complexity is sometimes very high, the volumes of data to process are often very large, and the communications overheads between bank departments are just insane. Quality (or lack thereof) has nothing to do with it.

potatolicious 17y ago

"There can be no rapid iteration, because every bug is disastrous" I work for a company that handles a lot of commerce, and bugs can be disastrous, and stakes are high - we still iterate. Sure, we're not pushing new versions live every single night, but our cycles are still relatively quick. I think the "there's too much on the line if a mistake happens" line of thinking is a cop-out. There are ways to mitigate this risk, safeguards and methodologies.

ig1 17y ago

Plenty of banks use agile development methodology.

gaius 17y ago
Plenty of banks also haven't touched code that's been running just fine for the last 30 years. You just upgrade the mainframe under it...
- AndrewDucker 17y ago
  Plenty of banks have both. That's the advantage of n-tier systems. You keep your ancient databases, stick some business rules on top in Java and then talk to them from a bunch of clients that you can tweak as much as you like without worrying that you're going to break the important stuff.
StrawberryFrog 17y ago
Plenty of banks want to use agile, because they've heard it's cool, is said to deliver more better software faster, and is attractive to good coder job candidates. How far they are actually getting with it is another question.

StrawberryFrog 17y ago

er, getting bugs out early is a major argument in favour of test-first agile iterative methods. You don't ship every iteration, but give it to the testing team. Would you get better results from giving your testing team a new release once per year?

omouse 17y ago
Getting bugs out early is actually a major argument in favour of thinking before banging out code. Tests after the fact don't do enough to lower the number of bugs there are.
- StrawberryFrog 17y ago
  Oh, where to start with this one... * No agile method stops you from doing a bit of design thinking before you code, when it is needed. Agile is against Big Design Up Front as a matter of course because it so often fails to be good design, or appropriate for what the business ends up wanting. * Lots of automated tests done while coding that allows you to think sooner and better about your code. decreasing the need for big design up front, and better suiting the design to what you actually find your needs to be. Not thinking beforehand is a risk for sure, but producing a big, inflexible, unsuitable design is another risk. I've seen it, you may have too. Thinking without testing the thoughts in code is bad too. * "Tests after the fact" refers to QA. Agile also emphasises unit tests before and during the fact. "Tests after the fact don't do enough to lower the number of bugs" is something that any agilist would agree with, but would recognise as an argument for agile. * Rapid release to QA allows actual users/sysops to see where you're going much earlier, hence mitigating major risk of building the wrong thing/right thing but not scalable/performant enough/etc.