How do you counter that "X" language isn't ready for "Banking" or X mission critical app?

Question

So today I was explaining how Groovy uses the "Meta Object Protocol" or MOP to someone. More specifically I was explaining how Grails and GORM use the MOP to provide dynamic finders. The queston I got once the use of the MOP was sufficiently explained was, "Would you use that technology in banking?". My answer is why not? I've worked at many investment banks and just about all of them has some form of Perl or other scripting language in production doing important tasks. I know tons of hedge funds using Python, so why is it strange to be using something that implements the MOP? After all this concept came from Smalltalk, and I know there are definitely several mission critical apps in smalltalk....

My answer to using it was, that I would use it provided I had a talented team that understood the important of having good test coverage. However, even in a pure Java system we should probably have good test coverage, it is just that some larger institutions have been slow on the uptake with TDD and unit testing in general.

Answer 1

Something tells me that "Would you use it in banking" might not be a great example of a mission-critical industry for much longer :-)

You're absolutely right though, when I worked at investment banks a number of our internal apps were written in Perl, and we had just started doing some basic Ruby development. Unfortunately, I don't know that it's possible to really counter this saying -- you'll find that the people you're trying to convince, in many cases, can't and don't want to be convinced.

Answer 2

My answer is "why is the question relevant?"

Better questions would be:

• "Is it is suitable for my purpose?" or in general, "What is it suitable for?"
• "How reliable is it?"
• "How cost-effective is it?"
• "How does it affect usability/number of bugs/production time/future improvements/...?"

Would you use an armoured van to transport vegetables? Would you use a laser cutter to slice your bread? Would you make hourly backups of your CD collection?

Precision and reliability may be important, but so are time and expense. I'm not saying that something "ready for banking" is overkill in other situations. All I'm saying is, whether or not something is "ready for banking" (etc.) isn't relevant to whether it's a good choice for another purpose.

If something is ready for banking, this might indicate that it's very reliable, which could indeed be important. Obviously the question you should ask isn't "Is it ready for banking?", but "Is it reliable enough?".

Answer 3

Well, with the current political situation where I am, I'd give the answer "no, I like this language and think it's really good!", then fall into the current stream of jokes about banks that are doing the rounds.

More generally, well, is it ready for banking? Also, for what task for banking? Banks do a lot of different things, (hmm, that sounds like the feedline for another joke about banks).

Really, "use it for banking" is meaningless on its own, and even some of the more mission-critical financial tasks could use something like javascript (not normally considered suitable for banking) in a glue-layer reasonably well (not to say it would be my first choice, just that you could).

I'd answer with a balanced view on what I did, and did not, consider it well suited for and why.

Answer 4

The question might also be rephrased this way:

What is the long-term risk of investing in this technology?

Each technology carries an investment risk. E.g., today, it might be a bit unwise to want to build a new mobile platform based on Java. The Java mobile platform seems to have a lot of questions surrounding its future.

Suppose you choose C++. The long-term risk is fairly low, there are 2-3 major maintained compilers for it. But you add the risk of binary incompatibility with the Next Great Chip ISA.

Suppose you choose Perl. The risk there isthe risk of two Perls weakening each other's community.

There is also the managerial risk of hiring people who can grasp the technology. Building an advanced Lisp system is something that will be riskier to hire for than a boring Java system.

There is also the corporate risk of long-term lack of support. Will Bug X be fixed? It's breaking our system... If a corporation is supporting the tech, it's likely that bug fixes can be somehow contracted to be priority fixed (MS does this for some stuff, for example).

So in this analysis of the question, it's a reasonable question, although ambiguously stated.