Bill Curtis, one of the people involved in developing the global standard for measuring the quality of software (CMM), has said that banks will stick with monolithic COBOL mainframe applications because they don't have the same security and performance issues as Java.
This is despite a number of high profile IT failures in recent months in the financial sector, including RBS' outage that has cost the company hundreds of millions of pounds, and widespread criticism of the outdated IT systems banks operate on.
Curtis, now chief scientist at software analysis and measurement company CAST, told Computerworld UK that the reason the banks are consistently experiencing problems with their systems is because the COBOL programmes aren't broken down into smaller modules, which reduces the number of defects experienced.
"COBOL programmes are monstrously complex, the average size of a COBOL module is 600 lines of code. The average size of a Java module component is 30 lines of code," said Curtis.
"A lot of the COBOL applications were built before there was a hard push and focus on modularity - in COBOL there is a strong correlation between the size of the system and the density of the defects. It's exponential. The larger the system, the higher the density of defects in each one hundred lines."
He added: "That's not true of Java and in the other modern languages. The difference being that modularity controlled defect density, it broke that correlation because these things are smaller."
Curtis said that this is a problem for the banks because most of their systems are running large COBOL 'monsters on mainframe', but to rewrite the systems in Java would be a disaster, he added. "If you go back and try to rewrite it all in Java it's going to be a nightmare. They could do it, but they would go through a period where the defect rates would sky rocket," said Curtis.
Also, according to Curtis, the old COBOL systems, despite the number of defects that occur, are actually more secure and fast performing when compared to the modern languages, such as Java. He put this down to two reasons - lack of exposure to the internet and a lack of skills in the Java developer community.
"There is one language that has a higher security rating than any of the other computer languages - that's COBOL. Why? It runs on mainframes, less exposed to the web. Also, they have been beaten to death for generations in an industry where security is everything," he said.
"The other thing we know about those programmes is that compared to Java, they are really high performing - Java has all kinds of performance issues. The COBOL programmes perform like bats out of hell, the banks have fine-tuned them over generations to run really fast - high throughput, high transaction, mainframe environments."
He added: "Some of the newer languages are not performance tuned in this way. Some of the Java stuff, our data is telling us, has a lot of performance issues. Some if this may be down to the language structure, but some of it is that the guys that are writing Java aren't your top computer science graduates."
However, to overcome the glitches and defects, banks should be analysing their code to figure out exactly how it works, according to Curtis. The problem the financial industry has is that the systems were created years ago and many operate with little understanding of why it has been engineered that way, he claimed.
"If you think about these old COBOL programmes - they are old, out of date and the guy that built them is probably dead. You're guessing as to what's going on, there's no documentation. They are monstrously complex, very hard to maintain and very hard to understand," said Curtis.
"What you need to do is analyse the code - CAST do this, but so do other vendors - go in and analyse the entire application. They need to really need to know the structure of all that stuff, it's lots of different things tied together and called an application."
He added: "I'd be very surprised if RBS aren't doing this. Depending on what the analysis is, you'd target certain things and go and rewrite some stuff."