Devs bashing out crappy code is making banks insecure – report The rush to improve system functionality is leading developers to knock out subpar code, posing a threat the security of major systems around the world, according to an extensive report. The software quality of financial applications is worse than that of those in telecoms and retail, according to the report. The study ( …
From personal experience developing for a trading company, the quality of work that was outsourced to Indian subsidiaries was utterly dire.
The problem was not their nationality but that these companies were basically revolving doors hiring the cheapest people they could find and retention was appalling. On top of that nobody EVER pushed back or showed any initiative to fix problems they found in the requirements or code. I'd often see code building SQL statements up by hand, or doing client side only checks on fields that should have been checked on the server side. The sort of thing that could be exploitable.
That isn't to say quality was perfect where we worked but there was a high level of business knowledge, development experience and fairly good retention so people didn't just sail off into the sunset after 3 months working there. That counts for a lot.
Well Said Sir. Sadly the multiple PHB's and Beancounters only see the labour costs and go Kerching and pocket their bonus.
The rest of us grunts are left to pick up the pieces and try to make their shit work at least a bit before we are given the old heave ho or our rates are cut so much that we leave and go elsewhere.
The result is a big pile of steaming cat poo that also rains cat piss on anyone brought into try to fix the problems.
OTOH, I developed a project last year in half the time that the Devs in Mumbai quoted. It has been in production for 7 months now and has had one bug and that was down to the original spec being wrong.
It can be done but just not by those code monkeys in S. Asia.
Ask them to go find a Left Handed 20mm Spanner. They might come back in a year.
Now my job is being TUPE'd to an Indian Company. All they want me to do is train my replacements who will work for 1/4 of my cost.
I'm off to pastures new in France. Even the 35hr working week seems to have more long term future that here.
The report did look at in-house and outsourced development (table 15 on p.42) and at offshore and onshore development (table 16 on p.43).
Contrary to the knee-jerk reaction to criticise outsourced, off-shore development as producing shoddy code - well, shock, horror, the results were just as good (or shoddy) as the on-shore developed code with no significant difference measured in almost all cases/criteria.
Based on the study data rather than personal anecdotes, the factors having the most impact were organisational maturity and methodology (although a nod to choosing Java EE over other tech gives a head start for this sample). So a sound approach to producing the software and the discipline to stick to that approach are more important than most other considerations. Seems fair.
"Devs bashing out crappy code" or "Crappy devs bashing out code"?
These guys work in the swamp of stupidity. I've been into the swamp and seen not just the poor quality devs but the off-shore ops team, the decades of under-investment and the careerist, ignorant managers.
There's next to no chance they're going to turn out anything other than crap.
All of what you say might be true, but why do you and everyone else believe what this firm CAST is saying to support their business? Check them out. They are a French firm who do a lot of work for French institutions and banks, some US banks and not by the looks of it much UK stuff. Obviously they are going to make the case that places where they are not involved have bad issues and places where they are involved are good.
Does this mean that the French, once they have the contract, spend more than 6 beans for the extra validation the outsourced coders have to do?
Without India, half our programmers would be underemployed, after all they are only employed to problem solve the issues resulting from shit code for cheap outsourced slave labor .
One day the cost of having "deniability" that comes with outsourcing will outweigh the fact that its 50% cheaper to do it in-house
Or maybe a non English speaking country has less incentives in outsourcing development to the usual sources of English speaking ones? Thus maybe more code is written by local developers who aren't paid nuts to allow outsoucers executives reap the difference?
If you are paid crap then crap is what will come out the other end.
Its not like the people being paid shoddy wages in India don't talk to their counterparts in the UK.
They KNOW how much their company has been paid for them to do the work, they are also generally among the most intelligent percentile of India, so well able to work out the profits they are not seeing a fair share off.
Or maybe a non English speaking country has less incentives in outsourcing development to the usual sources of English speaking ones?
There are plenty of ex-colonial Francophone countries with (headline) cheap labour (and cheap French companies looking to cut similar corners)
Second that, I worked with a prominent French SSL broker and the standards of code were horrific. On my first day i was torn a new one by the owner for reviewing production code and alerting them to a severe security vulnerability (one of a huge list). It says more that i found it in less than an hour into a review.
Not to mention the fact they had no controls over card holder data (No implementation of PCI DSS) and no intention of implementing such controls.
I left after only a short time and the owner repeatedly tried to prevent me getting a new job by offering very bad references that where wholly untrue and trying to enact a non compete clause in my contract, even when I had applied for to a totally different sector.
Obviously thats just one French company.
there is never any time to 'clean up' or remove Technical Debt in an Agile process.It is always the next bit of Shiny-shiny to be delivered.
Nonsense. I worked in a shop that took Agile and Devops very seriously, with the KANBAN board and story cards and everything, and thought there was a goodly stack of tech debt, those cards were up on the wall and regularly revisited and, where merited, moved over to the work-in-progress board.
If you've seen agile done as a means of ignoring tech debt, you've seen it done wrong.
Just you need to know how to write it, and be used to write it naturally. It requires training and skills, sure - but after a while it becomes natural to write robust code directly - without much need to retrofit security after, as a second thought, which requires more effort and increases costs.
Unskilled developers who struggle to write the basic code to implement the required features, are at a huge risk of writing fragile and insecure code. They will be so busy in trying to make things work, they will take shortcuts and avoid any safety belt. They are so obsessed with that unique code path that make a feature work, they can't see the many which could lead to disaster, and don't add those checks to avoid them, or use risky practices (usually copied from StackOverflow or the like).
Of course, the cheaper the developer (not the company offering its services, the developer actually writing the code), the higher the risk. It's a case of What You Pay Is What You Get.
But I've seen legion of managers stubbornly thinking developers should not be different from unskilled blue collars - because they use machine and software, and those should take care of the final product, as in any other manufacturing line - not the "operator".
Oh welll, an ex colleague of mine asked to move in another unit in the same company - just to find there he will be evaluated each month by SLOC written... what could go wrong in such software?
The report doesn't include any financial or cost factors. The factors with the most impact were organisational maturity and choice of methodology which feeds in to the idea that giving developers the right kind of organisational support enables them to deliver better software.
Would be an interesting extension to see whether companies with higher organisational maturity and better methods incur/pass on higher unit costs for development but get better results. Tricky to do such a study for all sorts of reasons I would imagine, but considering offshore is normally assumed to be 'cheaper', this still gave the same results as onshore (table 16 p.43).
Counter counter take.
It's all too likely due to the prevailing attitude of hiring the Pizza Delivery Guy to do "web stuff".
Preferable in "Node.js" because its "the new thing" and the sub-boss has a spotty-faced teen who likes it.
The low pay is an advantage. Because there is "pent-up demand" (anyone who utters that word construction: shoot on sight with a 12-gauge semi-auto) for low-pay people in high-skill jobs.And we want to work against that demand.
I once (a very long time ago, COBOL era code) had a contract conducting third-party QA on a major banks systems. I was handed a long long list of boxes to tick as a spreadsheet. The problem was I couldn't even tick half those boxes because the entire thing was so buggy and unstable - I couldn't even get to the stage where 'Do X changes Y and displays Z' because even going near X caused series of unexpected results. After a couple of weeks I submitted a report detailing how to reproduce the 'pre-bugs' that needed fixing and likely causes. Suggested they try to at least reach alpha stage before paying expensive contractors to conduct beta testing. Nope, contract cancelled immediately, sod off, project was already over-budget and almost complete. They just wanted someone to tick the boxes.
The findings are surprising
Not if you've been involved in software development for them. I worked for a short while helping rewrite some code for an investment bank. They were baking defects and poor design in right from the start. They seem to rely on thorough testing rather than good design and implementation.
In a culture of closed development, this is inevitable. What starts as a little bit of pressure (have you finished XYZ? Just about ...) then snowballs into botch and coverup. The original dev can do it in a few hours, except those few hours are needed for something else. The line manager becomes complicit after ticking the milestone, and then on up.
Sobering thought: the military is worse. And has the best culture of secrecy, so their cockups rarely leak.
More horror stories by Robert Charette in this PDF. More by that guy at the dreamy-techno-eyed IEEE Spectrum.
Always good to bring to the daily feel-good meeting.
This does not surprise me.
When you take a basic coder fresh out of university they will only have been taught what the course states and only learnt what they decided to research further themselves.
Code is not static or fixed, you can code the same action numerous ways yet only one will be efficient and only one will be truly secure as far as the coder can go in making it secure in their part of the code, sometimes you have to go to other coders parts of the program to ensure you don't inadvertently make that insecure.
Therefore to understand and account for these takes experience and time and that is what is lacking and causing these problems. There is also the rush to market which is rightly stated in the article as that which will inevitably cause you problems.
Until it costs more money because of the problem than it will cost to stop it then nothing will change.
"The findings are surprising, not least because financial service firms are regulated and run the risk of huge fines if security problems in their apps ever result into problems."
HAHAHAHAHAHAHA!
* reads it again
HAHAHAHAHAHAHAHAAHHAHAAHAHAHAHAHA!!!
Yes. Right. No. let's just say... security in financial services is, shall we say, "variable". Of course the megacorps have more of their waterfowl arranged in a ragged line, but IME there are skeletons in some pretty gigantic cupboards that would raise an eyebrow among any group of competent network, computer or security architects -- or engineers.
Personally I'm still waiting for the financial fraudsters to notice that many hedge funds and boutique fund management firms are both tiny - headcounts of <50 are very common - and handle gigantic sums of money. It's only obscurity that's kept them mostly fairly secure to date, and we all know the problem with relying on that to keep you safe and solvent. Sooner or later some people are going to lose a lot of money and others are going to be buying themselves Caribbean islands as retirement homes.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
