The average lines of code (LOC)
I thought we threw this out in the 90's as a "useful metric" for measuring code?
And so what if they're using older tools, they're more likely to be more stable than "cutting edge".
If it works...
App developers in the UK banking sector are lagging behind their European and US counterparts in tools and methodologies, according to a new study based on code reviews. According to the survey, most British banking apps are developed using three old-school technology stacks including COBOL and Oracle Server. European apps, by …
IDENTIFICATION DIVISION.
PROGRAM-ID. TARD01.
ENVIRONMENT DIVISION.
SOURCE-COMPUTER. UNIVAC 1100-80.
OBJECT-COMPUTER. UNIVAC 1100-80.
DATA DIVISION.
PROCEDURE DIVISION.
DISPLAY "HELLO WORLD" ON CONSOLE.
Eight lines. Might need a WORKING_STORAGE and a dummy 77 level data item to compile elsewhere, for ten lines. Needs more verbage if compiled in UCOB because the class of '86 wanted to make everything look like Fortran for some reason, but not more than four or five lines.
Trade in your CS lambskin, and stop making pronouncements from the mountain of "everyone knows" based on the one course you took and slept through. Your "famous" source is full of snot and one who is frightened by any language that looks different from the C-Like pap he/she learned to digest at school to boot. I make rude noises in both your directions.
8op 8ob 8op
Thrrrrrrrrrrrrrp!
"Trade in your CS lambskin, and stop making pronouncements from the mountain of "everyone knows" based on the one course you took and slept through."
Can't say I blame an uninformed opinion even with a CS lambskin. My degree course in the mid 90's was full of professors telling me 'nobody used COBOL anymore'. Used it all the time on my first two jobs....thankfully I had a more useful HND without the baseless prejudice already under my belt.
Yes. So much less better than a semi-colon needed wherever it isn't forbidden or (shudders at thought of debugging a rookie edit on important code) significant leading white space.
If you need a real reason to hate Cobol that isn't completely fatuous and based on erroneous axioms, they are actually periods, not "full stops" because Cobol is an American computer language. Let the xenophobia begin!
But then again so are C [insert flavour of the month], Java and perl. Oh well.
But you do with 1100-80 compiled ANSI Cobol 77, which is what I was trying to write.
You'd compile it with someting like @ACOB,CRYPES KRIKEY*WHATTA.TARD01
If you felt so inclined and had a Grey Goddess lying around somewhere.
You might need to say UPON CONSOLE rather than ON CONSOLE. I haven't written any Cobol since the late 1980s.
If you've ever spent time mentoring inexperienced developers, you'll be familiar with the "clever way of doing something".
The kiddie manages to compress something into a couple of lines of code, perhaps using undocumented features. At best this results in something that's hard to understand and maintain; at worst, something that's broken in a subtle way that will only become evident after release. In all cases, the LOC is smaller.
Code spends most of its life in maintenance, so anything that makes things clearer is a good feature.
"Code spends most of its life in maintenance, so anything that makes things clearer is a good feature."
And it was always thus. You know that, I know that, so, in all probability do most readers of elReg. So why do the Continuous Lifecycle mob treat it as something they just invented?
LOC was thrown out as a useful measurement for *coder productivity*.
It used to be assumed that the more LOC per day, the better the coder.
Now it is often believed that less is more, simpler is better, so actually writing negative LOC could be a very good day indeed. Hence the argument in the article that fewer LOC in non-British banking apps is a good thing.
Fewest comments is best?
LOC is basically as useful as you would expect for a count of the number of LF characters* in a file. It is a very accurate measure of Lines of Code, and completely useless as a measure of anything else.
Anyone using LOC as a measure of anything other than the popularity of LF chars is deranged, and should not be allowed to publish papers.
* With apologies to those who use CR or CF/LF, although I admit some counting programs cannot handle this kind of complexity,
Compiled size?
Tom.
The article says that the UK has over a million lines of code compared to tens of thousands in european and us applications.
Odds are we have so much more code because of the older tooling and languages, the European and us code will JUST be the application code not the frameworks that they run on, where as ours is everything because the languages we use predate usefull frameworks.
I think that LOC as a measure of programmer productivity went out in the 90s when a number of programmers who weren't prepared to continue playing along started being factious and filing negative values for the lines of code they'd written during code optimisations.
As a measure of code quality it could still have some use (more LOC = more scope for bugs, harder to maintain, etc) but you have to offset that against the complexity of the problem being solved. An image viewer is always going to have fewer LOC than a database (unless the former is really sloppily written). If comparing like for like applications with similar levels of functionality I'd tend to prefer the one with fewer LOC
Lines of code is a useful metric for understanding how much info devs need to understand when working on the code. I.e. it's one input into how complex the codebase is.
As others have mentioned, it's of no value for assessing whether an individual dev is any good or not. It's no good as a target but can tell you something about system complexity assuming your devs aren't over optimising for conciseness.
"According to the survey, most British banking apps are written old-school technology stacks – Java-EE, COBOL and Oracle Server products. European apps, by contrast, use approximately 17, while eight are in use in the US, which uses a wider range of technologies."
I'm no expert, but can someone add the missing words for me please?
"I'm pretty sure the /apps/ per se aren't being written in COBOL and Oracle Server. Are they somehow including the backend all the way back to the mainframe as well?"
I also did a double-take on this one. I suspect they're just talking about the applications that runin the data centre but someone trying to be trendy has called them "apps".
"I also did a double-take on this one. I suspect they're just talking about the applications that runin the data centre but someone trying to be trendy has called them "apps"."
I assumed from the article title it was about customer banking 'apps' (mobile/etc) it's only when I got into the article itself that I realised I had been misled.
I've used 'apps' myself to refer to non-mobile device programs (because the line between the two are thinning what with MS UAP and rise of app-stores carrying all desktop software (that and the convenience of having to type less), but I'd never dream of using 'apps' to refer to enterprise level software.
Unfortunately, the linked report is a bit light on detail and you have to realise that it is written in support of the product used to do the analysis:
CAST Application Intelligence Platform (AIP) is an enterprise-grade software quality analysis and measurement solution designed to analyze multi-tiered, multi-technology applications for technical vulnerabilities and adherence to architectural and coding standards.
The applications they have analysed are those voluntarily submitted to its database of "typical" applications. They include:
172 applications written primarily in Java-EE, 156 in COBOL, 19 in JSP, 16 in .NET, 15 in Oracle Server, 12 in PL1, and 42 written in other languages such as C/C++, Delphi, Pacbase, C#, PL/SQL, etc
They're regular back-office applications, in other words, not your flashy mobile front ends. I can find nothing in the linked paper on "technology stacks" - I presume that detail came from the accompanying weekly Monday press release that CAST has yet to put on its website. I hope, if they analysed "stacks" they analysed the quality of the third-party code as well as the banking application itself: if you can't audit all the code you're using, regardless of origin, it's difficult to come to a realistic conclusion about quality or security.
There are some interesting conclusions, though they're likely largely irrelevant - no-one is going to trade the stability of a mature 200K LOC banking application for a modest increase in its security or maintainability by rewriting it in Haskell, though they may be a pointer for future development efforts.
Though not entirely. COBOL applications are generally more secure by itself, is not going to lead to COBOL becoming the language of choice for future systems development. Batch applications are in general more secure than interactive applications, and they're more likely to have been written in COBOL, though it's unlikely anything new would be. On the other hand, in terms of methodologies, the conclusion that Waterfall leads with the most secure applications on average, while Agile has the lowest score is hardly a surprise; nor is Small development teams globally deliver the best code quality.
I would definitely say that if your aim is to write a streamlined, extendible, well crafted, fast and flexible system, then writing it in Java is not the way to go. However if you want to put off implementation decisions for as long as possible whilst appearing to be fully productive, Java's definitely the language for you.
Getting time of day in an architected 'enterprise' Java System written by 'enterprise' Java developers in an Agile fashion:
time = serviceFactory.instance().getProxy().getMetaProxy().getRealProxy().
getServiceOfType(serviceTypeFactory.getProxy().getInstance().getType(
com.verbose.consultants.services.ServiceTypes.TIME_OF_DAY).
format(serviceFactory.instance().getProxy().
getMetaProxy().getRealProxy().getServiceOfType(
serviceTypeFactory.getProxy().
getInstance().getType(
com.verbose.consultants.services.ServiceTypes.TIME_OF_DAY_FORMATTER).
setDefaultTimeOfDayFormat()).
getFormattedValue(
com.verbose.consultants.formats.time.TimeFormats.TIME_OF_DAY)
In Python:
time = time.time()
1) When they say "UK" do they mean *in* the UK, or *from* the UK. Given my experience of offshore code quality, I suspect the latter.
2) Why is old tech automatically seen as somehow bad. There a reason the worlds banks run on "old" technologies. Tried and tested for one. I'd rather go into space on a 50+ year old Soviet rocket, than the latest gee-whizz from anyone.
3) Irrespective of "apps" my experience of most of the worlds financial environments is that they are light years behind the UK. The UKs financial services market is probably a world-beater. I know that sounds a bit crazy, but try and setup and manage a self-invest ISA in France or Germany, before you start laughing.
"a certain sub-continent where the focus on security and performance are lucky to have someone even passingly familiar in the concepts"
Frankly in my experience you're lucky if the "coders" they put on the job are even passingly familiar with core programming concepts and algorithms. Judging by code I've seen, most of them have just graduated from doing ZX81 Basic.
Still, you get what you pay for. Sadly UK IT managers are a fairly dim breed and don't seem to understand that a million monkeys generally doesn't result in Shakespear no matter how many peanuts you throw at them. If you want quality code you need to hire quality coders.
" The UKs financial services market is probably a world-beater. I know that sounds a bit crazy, but try and setup and manage a self-invest ISA in France or Germany, before you start laughing."
Whereas I have sampled retail banking in both the UK and Scandinavia, leading me to the conclusion that UK banking is on the edge of third-world status. Clearly the mileage does indeed vary.
If the Uk Retail banking is close to being 3rd world status then what world does the US Banking system live in?
5th World?
Getting a payment between a bank in AZ and a bank in MA took (last year) five working days.
It even took three days to get payments between accounts with the same bank but in different states.
You don't even want to think about the time it takes to get a check (us spellling) cleared. No wonder business are very loathe to handle out of state checks.
My experience of looking at outsourced code was to conclude that the coders never had a chance to query what the specification really meant. It may have been due to the price of phone calls from some countries, and also a reluctance by the outsourced bosses to admit to problems.
My experience of outsourced development is that it's often as mixed as it is in the UK. I work closely with devs in India, US and Poland... Generally all are alright developers... You get the occasional bad egg, the occasional wizard.
I find the larger issue is that of culture, it takes me a good few months to convince Indian devs to ask for help if they are stuck, that there's no shame in needing clarification or asking for a second set of eyes. Normally in the beginning they'll struggle for days or weeks, and some just drop off the grid entirely.
If you have catch up meetings regularly, drop the ones who can't adapt (after a decent amount of time), and make sure you give your local teams enough support to run projects without a "ship it" mentality then there's no reason why off shoring is any worse than local development.
"Tried and tested for one. I'd rather go into space on a 50+ year old Soviet rocket, than the latest gee-whizz from anyone."
This is a common sentiment, but somewhat misguided. Said 50+ year old Soviet rockets actually have rather high failure rates - over 10% for both Proton and Soyuz types. More recent, non-Soviet rockets are almost all better; Ariane 5 around 5%, Delta-medium and Vega have never had any failures (Delta-heavy had one, putting the whole Delta IV family still only at 3%). Even Falcon 9 with a couple of high profile failures is still better than the Soviets at 9%. Tried and tested often simply means "tried and found to be just about good enough most of the time".
Software is no different. Old doesn't mean it must be bad, but it doesn't mean it's been well tested and established as more reliable than new either.
"There a reason the worlds banks run on "old" technologies. Tried and tested for one. I'd rather go into space on a 50+ year old Soviet rocket, than the latest gee-whizz from anyone."
It's a balance between how proven the old and the new are. I'd rather go into space on this years model rocket if they've proven for a few months they can launch 10 a day than the 50 year old rocket that's only ever had 10 launched.
Banks are careful about the technology chosen, but as the proven technologies get older the number of experienced people in the world is actually falling.
I can't help but think these apps are just a reflection of the back office technology they have to talk to. Despite Britain being renowned for it's financial services, which rank among the most advanced in the world, it's junior member the retail banking sector is definitely not part of that advanced world.
If you see how long it took Britain to introduce Chip and PIN, that it's 2016 and the UK still has (and uses!) checks, that Britain is still hooked on the outdated and inflexible Sort Code+Account system instead of the IBAN system that dozens of other countries have already moved to, that transferring money to a neighbouring country still requires jumping through all sort of hoops and eye-watering fees as if it needs to be telegraphed to Rhodesia in the 1950's, you can see that Britain's retail banking could do with keeping up with the 20th century. Perhaps if they speed up they could even enter the 21st century.
Beyond charities and student clubs etc, I actually don't know anyone using cheques. Most (all?) banks have stopped issuing cheque books unless requested by the customer. IBAN and international payments comments are true enough though
EDIT: And on cheques let's not even start to talk about the US system and their literal paychecks!
Until two years ago I had to pay my monthly rent using cheques, my landlord refused any other sort of payment. That is, of course, because he was behind the times but the fact that banks even still offer it means it can take a terribly long time be replaced for some people. HMRC still uses cheques by default for VAT repayments. If you want to have it deposited automatically into your account you have fill in a form and go through a telephone interview!
Other countries have pensioners that may need some extra help switching too. And yet some have managed to abolish cheques more than a decade ago.
Of course, there are countries that are far worse. The business of a friend of mine signed a software contract with a US local government and this government could only pay by sending them a cheque for over two million dollars!
Well I still use a steady small stream of cheques, mainly for gifts and sometimes for larger payments to contractors. I rather like the audit trail attached to them as I know to whom I have paid the money. Though I agreet that I do settle bills for regular accounts via direct means.
I read too many accounts of transfers, (as opposed to settlements) being made incorrectly and with my dominant hand currently out of action the risk of error is greatly increased.
Or should I wander the streets with cash? That is not easy as I have trouble with a foot which awaits NHS action.
I am the Treasurer of my local town twinning committee. We use cheques for two main reasons: we do not have the business status to collect direct debits for subscriptions; and we require two signatures for payments. That latter is a protection for us committee officers as well as for the money.
Our German counterparts, however, use giro transfers to receive payments for the events they organise. I have not yet asked them about payments: do they need multiple authorisation, and if so, how is that arranged?
One problem we have: for every event we organise, some cheques arrive payable to the organiser personally rather than to the twinning association. Fortunately our bank is sympathetic to these things.
Of course, that's how you create an IBAN. Unfortunately the UK (in its quest for complexity and inconvenience) kept using the old system alongside it. For instance, all countries using the euro had a hard stop on 1 Februay 2014 after which the IBAN system was the only system allowed. Apparently towards the end of this year Britain will have finally migrated to a full ISO 20022 system but I'm not holding my breath. If retails banks can screw it up, they will. After all, why make it easier for your customers?
"it's 2016 and the UK still has (and uses!) checks"
While technically true that the UK does still have and use cheques, in reality barely anyone does day to day. I still have my chequebook that was issued in the early 90's, I'm about half way through it. There has been talk of withdrawing them for years but they are still kept for compatibility. The only thing I use it for are companies/clubs stuck in the past who don't accept debit/credit cards.
The same with chip and pin, that has been around for most of my life, but the magstripes were only remove from cards recently as removing them earlier meant the cards couldn't be used in other countries.
"While technically true that the UK does still have and use cheques, in reality barely anyone does day to day."
Whose reality? While I do online banking and payments I still use cheques to pay plumbers etc whereby its much easier for them to take a cheque than pay for and carry a chip+pin system around with them. Also the bonus of a cheque is that because it takes 3 days to clear you have 3 days to cancel it (albeit with a cancellation fee) if the work turns out to be shoddy. With direct payments you'd have to go to the small claims court to get your money back.
I consider TransferWise to be part of Britain's retail banking sector, and haven't encountered significant hoops or eye-watering fees when transferring money overseas for many moons now. Innovation is alive and well, you just have to see beyond your legacy bank and it's bundled current account services if you want to find it.
Until such time as the financial services sector comes up with another way to do the job of a cheque, they are here to stay.
Maybe they are cumbersome, clunky, old-fashioned, and laughable.
However they provide a unique function. The ability to transfer money to a person - not an account. As long as there is a need for such a facility, cheques are going nowhere.
Spot on Mr Page.
With a cheque, I can decide myself what bank or building society (or other) account it is deposited in.
Will the cheque nay-sayers please give me another method of doing this?
Even with some financial instutions, payment by cheque is still the norm.
I cashed in part of a stocks and shares ISA last year. The amount came by post in the forma of a cheque.
The Scrap Metal Dealers act 2013 mandates payment by Bank transfer or Cheque to create an audit trail for ALL transactions, paying by cash is actually a criminal offence. Even if you scrap your own car with a v5 document in your name you cannot be paid for it in cash. This allegedly stops theft of cables road metals etc, in reality it does nothing to stop that as the thieves know who the bet dealers are that will work around the legislation.
For casual purchases, the average scrap dealer will use a cheque for cost & time efficiency - it isn't worth setting up transfer routines for occasional or one off customers, that is just one more reason for cheques to be retained, the banks are just not small transaction friendly.
Electronic payments are not the be all and end all some make them out to be.
"Will the cheque nay-sayers please give me another method of doing this?"
The nay-sayers are generally millenials suffering from confirmation bias, who think that because them and their spotty faced mates don't need a particular service, *nobody* needs that service, coupled with their naive belief that anything that isn't digital & online somehow just doesn't cut it.
Naturally the banks are happy to oblidge them in their fantasy and try and end the cheque because processing cheques costs the banks money since (horrors!) they have to employ actual humans to do it!
"With a cheque, I can decide myself what bank or building society (or other) account it is deposited in.
Will the cheque nay-sayers please give me another method of doing this?"
The usual method seems to be telling the payer which account you want them to send the money to. Amazingly, it generally works quite well.
If that's too much trouble for you, then many bank accounts have this incredible facility where after you have deposited money into them, you can then move that money to another account (even at another bank!) by clicking a few buttons in an app. Staggering technology, eh?
This post has been deleted by its author
Well there's a few things in here that raise questions.
My main one being how does the marketing budget of a bank compare to the training budget for it's IT staff. And I'm not talking about about Cisco, Oracle or whatever certification, but general training on software design and security. As branches are cut back and online\telephone banking becomes the first point of contact with your bank, the people who design and write the software become the invisible face of the bank
If all they are asked to do is keep the heap of legacy crap going then nothing will change.
Nothing wrong with COBOL as such. It's the stuff round it that makes a stable system.
If you're advocating using something like node that changes every five minutes you really were born yesterday.
The processing power in modern banking systems goes not on transactions, which are simple and well understood, but fraud detection.
This post has been deleted by its author
Britain was a pioneer of computing and so we have built up a lot of legacy systems over the decades, this is why COBOL is still very prevalent. Johnny Come-Lately's can make a clean start with the technology of the day and write more concise code with more detailed requirements.
How do you make a valid like-for-like comparison between a new current-account-only startup renting (say) Temenos in the cloud and an established bank with a portfolio of systems for trading, loans, current accounts, mortgage, etc, etc? It's like comparing a bicycle shop with Ford.
You can't/ Which was your point.
As I am currently overseeing the service transition of a well known uk high street banks Internet banking platform this article interests me . . . but the complete lack of any substance to do anything with annoys me. I don't remember the Register regurgitating press releases without any journalism being added so much.
Can we have the old Register back please.
HSBC, Lloyds, Barclays banking apps are utter crap. You only see this when you are shown how it should be done by banking in Australia. Commonwealth Bank of Australia leads the pack by far. Neat, simple to use, and can do everything you need to, and is a secure phone app. Old Internet banking from a PC is pretty smart there as well.
"172 applications written primarily in Java-EE, 156 in COBOL, 19 in JSP, 16 in .NET, 15 in Oracle Server, 12 in PL1, and 42 written in other languages such as C/C++, Delphi, Pacbase, C#, PL/SQL, etc"
So learn Java and COBOL is the career plan?
Anyone recommend a good place to start for COBOL, above and beyond what google will do? :)
Would it be within el Reg's remit to compile outages, crashes, downtimes, ... , other abominations on european or world wide basis?
Maybe there are indicators in the downtime metadata to show trends?
Equally if some organisations are already doing the compiling could el reg gleam it for wider perusal?
Just asking that's all.
Banking Tech sucks anyhow. My local HSBC removed the old green screen ATM after years of sterling work and replaced with with an all singing all dancing colour monitored model, except.. the new one doesnt have a pay in facility which the old allegedly obsolete model did.
Being told internet banking is available 24 hours isnt helpful, I have yet to find the app in ANY bank that allows me to pay in actual cash money out of hours. They compounded the lie by saying the facility is not included in modern machines. Strangely others of a very similar vintage and style do - but thats other banks. Its almost like the banks don't want our money! The people behind this stuff are the same ones who fail repeatedly to see a modern stable and secure platform underpins UK consumer banking.
All UK banking apps and web pages are crap. I have used them all. HSBC just terrible. The best I have found slick and fast and able to scroll back in time with ease is Commonwealth Bank of Australia's (CBA)
I doubt written in Blighty.
Web and app are all I need. The app does it all, seldom if ever need to use the web version. Secure, two factor.