I think the biggest obstacle is actually the bankers. They do not like adopting new functionality, especially new functionality that causes their processes to change. They have no problems with tech that lets them do exactly the same thing they were doing before, like say, mobile apps, but new = scary. For example, in the ACH file description, there are two file format types: One is called 'DISK' and the other is called 'LINE' - for dial up. They just send the disk format now, over the net.

In short, they do not trust technology to get it right, and so will only accept a process that's modeled after their actual pen-and-paper model, so they can manually validate the results and understand exactly how it works. Then, once it works, they won't change it.

You also have the additional barrier of existing legal structures in the US that force a 'float' time to all transactions, but that would change if the bankers (and I guess, the market) demanded it.

It's all moot though. There's not a big need for minute to minute liquidity except among those who are very bad at managing finance, and they do not make for good customers. I honestly don't see a real market need for that sort of feature, nor people who'd pay for it, and so no real ROI on implementing it.

We already use 'risk scoring' all the time; it's a fundamental part of our ATM software, and nowhere near as magical as it sounds. They're usually just fixed rules, like "no more than $500 dollars a day, or $200 per transaction" etc.

As for being available for business transactions, I didn't see that specified. If this is a replacement of ACH transactions, then it's likely that it works fine for people too. You know, most banks implement billpay via ACH transactions from a person (when they don't have to print and mail the check). It's just that things like payroll and issuing collections (like invoices), or transferring money to another account at a different bank are not standard end-consumer needs.

Side note: There are many other notes about realtime money transfers in other countries. In most cases, those are again, time delayed at some point, and subject to reversal, it's just hidden from the customer. In fact, even wire transfers/money orders are reversible! The countries involved simply have laws pushing the risk elsewhere than the customer - usually the FI, I'd bet. This is especially true of large international exchanges, like SWIFT. You might even be able to pay more to such an exchange to expedite your transfers, or even cover the risk - for a good customer.

Though, that said, there's no reason a bank in country A might not have an agreement with country B, to automatically honor requests, assuming both countries have lax or non-existent financial regulation laws. In reality though, all countries have those laws, and that's why we have international exchanges.

This is not just a semantic difference either; there appears to be no difference to the customer in most, but not all circumstances.

Disclaimer: I used to write banking software for a living, including implementing ACH management on both the customer-facing and backend processing systems.

The article is blatently misleading regarding realtime transfer of funds, but it takes some knowledge to understand why. Let's talk about ACH transactions.

ACH, or Atomated Clearing House, is the network that the majority of electronic funds in the US use. As the article points out, it's ancient and horrible, basically a 1:1 translation of the paper funds reconciliation to electronic format. In essence, a customer creates an ACH transaction, which is sent to two endpoints; the federal reserve a.k.a. The Fed, and an ACH operator. Just like a credit processor, the ACH operator is then responsible for delivering the funds to the destination financial institution (FI) and they make their money by charging the originating FI. The transfer only goes through once both The Fed and the operator finalize the transaction, which can take a day or more, and most of them are held for additional days to provide for reversals (effectively, cancellations).

Here's some important takeaways:
    - To perform bank-to-bank transfers, you must either engage a third-party processor, or you must have an agreement (and process) with each individual bank you wish to transfer to.
    - These transfers are subject to some very specific banking regulations, some of it relating to reporting to the Fed, who can block the transactions.
    - Laws provide for effective reversal (issuing a reciprocal transaction, not necessarily a reversal) for 2 days for corp-to-corp transaction (CCD) and up to 60 days for transactions involving people (PPD).
    - Just like most retailers, these are batch processed, not in real time, though the banks will reserve funds and adjust your balance accordingly. No one minds because legal protections result in at least a 2-day processing window anyway.

Okay, so what do we need to perform this transfer in realtime? Well, first, you'd have to get every bank in the US and the federal reserve to switch to a new system that actually supports real time transfers, instead of the ACH. Then we'd have to completely overhaul the 40+ years of recent laws that were written with a batch-based system in mind, including removing many of the funds reservations activities (and the legal protections that require them) in favor of a realtime system.

So how does this bank do it?

Based on the info from the article, it sounds like the bank is managing two accounts per individual account; the customer-facing one which serves the 'realtime' aspect, and the actual one that is used for the ACH transaction. The risk comes in when the bank accepts a credit or debit prior to it being authorized and completed, and thus the need for 'risk management' software, identical to the sort that ATMs use, especially when configured as a local authorizer (for branches too far from the main branch and others).

They just don't show the end user the reservation of funds like most FIs, and they assume the risk directly so there's no odd 'processing' credits or debits in their statement.

So, it's just smoke and mirrors. They have to use ACH if they want to talk to other banks, and they're not doing manual wire transfers. They just aren't telling their customers. Though if they hit the anti-terrorist check (I wrote the software that matches against the government list too, at one time), their customer is going to find out really quickly that it's really just an ACH after all, and they ~don't~ have those funds - it's illegal for the bank to provide them!

This isn't a matter of lack of knowledge or understanding. The US doesn't need to be taught, or led.

The US is currently on the divide between protecting consumers from potentially abusive practices or allowing businesses to run rough-shod over them. It's a debate regarding priorities between business, consumers, the economy, and social welfare, and despite my strong feelings on the subject, on a national level, there's no silver bullet answer that 'fixes it', especially since Canada hasn't actually done anything either, but commission a study.

In fact, studies of the sort that are being done in Canada have already been done in the US, at several different points in time, and the recommendation they had then was one of non-interference. With the inability for congress to act in any way other than to block action, that's likely how it's going to go.

What we could use is a surefire way to figure out how to light all the democrats and republicans on fire, and replace them with politicians that actually care more about the people they're meant to represent than their next elections, party, or party politics. If you've got one of those, let us know, cause THAT's what we're in dire need of.

I'm pretty savvy with all the listed languages except Objective-C (only maintenance on existing apps), and have used them all at one time or another in a job. My linked profile garners around 3-4 recruiter contacts a week, and in my own little silo, I can say that while there may be 6 figure salaries out there for the Python and RoR, they are few and far between. The salaries I'm seeing on the top end for those development jobs rarely crest 70k.

On the other hand, there's bigger salaries for Java or C#. It's not too hard to find a 100k-110k senior Java or C# developer position.

Anecdotal evidence is not scientific data, but their results just don't match my personal experience in 2 decades of doing this.

However, I think I can see how they got the numbers.

According to the article, the data was retrieved by searching job ads, as opposed to taking a survey of people actually working at those jobs, and then permuting and filtering it. Given that:
    - Development job availability, especially with new technologies, is heavily skewed towards the west coast, where the cost of living is higher. From Austin to San Jose, the cost of living increase is between 50 and 75 percent - the 100k job is at least a 150k.

We can make a reasonable assumption that there will be more positions open, and that more of them will be higher paying relative to the entire US job market, likely breaking the 100k cap, as 100k is low relative to the cost of living.

    - Established development languages already have a majority of their positions filled, as opposed to emergent technologies which have more open positions

This will naturally result in a higher number compared to a language with less open positions, if the bar (100k) is low relative to the cost of living.

    - Emerging technologies lack experts simply because they haven't been around long enough to develop as many

So positions will be open longer, and more aggressively marketed by recruiters, meaning that they're more likely to double- or triple- count job postings that are unknowingly for the same job
                          &
Employers using recruiters often prefer to using a limited number of recruiters who themselves maintain a pool of direct-contact individuals with experience in a given field, meaning that those jobs are less likely to be publicly posted, whereas the new technologies require public announcement and investigations.

So in summary: I don't doubt the statics they used, but I think their methodology may be affected by a heavy bias, and therefore invalid.

Let's say it exceeds our own intelligence, that's fine - but you have to ask what purpose it has.

Take a human. What they do is based on what they've defined as their purpose - their goals both second-to-second and over their whole life. There's a whole series of organic processes which result in the determination of purpose and it's pretty random in part because we don't have explicit control over our environment or our thoughts.

However, (important) AI's won't be like that. We'll have control over their entire environment, and they'll be purpose built. You'll say "We need an AI to manage traffic," and then build that purpose into it. You won't take a randomly wired mechanism and plug it into a major public utility control panel. You won't worry that it was exposed to, and then became enamored with violence on the TV and decided to be an action movie star, and so is going to spend it's day watching rambo reruns rather than optimize traffic lights. The core of it's essence will be a 'desire' - a purpose - to manage traffic.

The end result is that AI's won't act destructive, threaten humanity, etc - unless we tell them to. In this light, the thing to watch out for would be military usage. Maybe don't put an AI in charge of the nukes. You'd also need to - among other things - allow AI's to have the freedom to NOT fire on an enemy, for example, because of the very mutable definition of the term enemy.

Additionally, I commented on prisons and public shaming earlier this year, referencing the same book: http://slashdot.org/comments.p...

Responded up in http://slashdot.org/comments.p...

caveat: I did not produce any sources which one could validate online without paying for journal access.

However, if you do any research at all on this topic, you should be able to find the resources on your own, even online. This is such a widely known & accepted fact that it's not really considered that interesting.

Ooch. I knew this was coming.

I have about 4-5 textbooks from college, and the one I enjoyed the most out of was this one http://www.amazon.com/CRIMINAL... though it's probably quite dated by now (published in 1981).

Otherwise, there's scads of both psychological and sociological journals with papers on it ... but they're all behind paywalls. For example, http://pss.sagepub.com/content... is a very recent study that says, basically, if they feel guilty, they'll be less likely to re-offend, but shaming makes it more likely: "Further mediational modeling showed that shame proneness positively predicted recidivism via its robust link to externalization of blame."

That shaming doesn't work is really well known.

In fact, we have a great deal of information about what does and does not work when it comes to crime and punishment, and largely, it's politically and emotionally charged individuals that ignore the scientific results. For example, 'nice' prisons don't affect recidivism rates vs. 'mean' prisons, within the same culture, but people point to say, a prison in america and a prison in norway and think that's a 1:1 comparison that only involves prison systems, when it's clearly ignoring important variables.

Really, the most cost effective way to deal with crime is to make sure it doesn't happen. That means promoting education, nuclear families, and work ethic, and there's statistics to back that. Educated, job-skill-having individuals with a stable home life tend to avoid criminal acts.

It's just not politically correct to say that, for a number of reasons, much less enforce that sort of policy change.

I know it feels good for the public at large, feels like karmic justice, but it doesn't hinder offenders.

Having done a good deal of research into crime and punishment, it turns out that shaming punishments have no statistical impact on the chance they'll re-offend. Anyone who is even briefly ostracized from society will be at least as likely to turn to alcohol or drugs as they were before, and other potential impacts like losing their job or positions of respect further worsen the odds of recovery.

What does work for DUI cases is to provide access to rehab clinics followed by support organizations, though apparently not any of the -anonymous ones like AA or NA, which have a worse-than-nothing recidivism rate.

To combat the growing congestion and to meet ever-more-stringent environmental concerns (both for the sake of the environment and because it makes a place nicer), we'll block off most of the high density cities to standard auto traffic, and instead a city (or licensed companies) will maintain a fleet of local-only self-driving cars that work as taxis along side the few human-operated larger delivery vehicles. Whatever the form of ubiquitous computing is around (cell phones, etc) will allow on demand pickups as well as scheduled trips (commuting, school, etc) and even provide for things like package delivery.

Eventually car ownership in certain cities will be seen as completely unnecessary or too high of an expense, like in Tokyo, for example. Since the urban sprawl appears likely to continue to grow, it seems that this trend only become more and more likely. Personal car ownership - like in the demo - will be a rare thing, and you'd never use it living minutes from downtown anyway.

You'd think a 'future vision' company would know better than to provide some sort of brochure site that acts and works as poorly as this one does. Navigating through this was like trying to play a first person shooter using chopsticks to control the keyboard and mouse.

On time completion: It will be done as soon as it can be done, only experienced teams can provide reasonable estimates, developers provide timetables not managers, there's a specific amount of work that must be done before release and putting dates on it won't reduce the total amount of work that needs to be done.

Unclear requirements: It's now the developer's job to talk to the stakeholders and find out what all the requirements are at the point in time they need to size or implement them. They get a vague 'story' that gives an overall concept of a requirement, and then it's up to the dev to talk to whomever needs talking to, then.

Changing requirements: This happens and everyone expects it. So you do only the least work required to complete each requirement so the overhead in a change will be the smallest, and then you just pop that item on the queue and it gets done, that's it.

Context switching: Tasks are assigned to a team by managers, not as a sole developer, so if context switching is causing a problem, it's up to the team to figure out how to minimize it.

Take responsibility: They are, and increasing the duties that a developer has, while removing certain responsibilities from managers and product owners, which more accurately represents the reality of the situation.

Caveat: Recent studies have shown that Agile is not as good as a waterfall-agile mix, where you do a good amount of planning (especially architectural planning) prior to the agile-like development, which makes a lot of sense. If half your work effort is refactoring, at some point you start take a severe hit to either efficiency, quality (robustness, maintainability, operational limits like memory or speed, etc), or time.

I've written about this several times prior, so I'll just summarize those arguments here:

College is not meant to provide job skills : http://slashdot.org/comments.p...
The majority of what developers do does not require advanced skills: http://slashdot.org/comments.p...
You don't need much training to get to a point where you're employable: http://slashdot.org/comments.p...

There's other points too;
      - Once you have learned some language to a given degree of proficiency, you notice that the rest of the languages are little more than different syntactical sugar and different naming for built in functions/libraries.
      - Learning how to learn is more important, as our development environments change so often that it's expected we'd pick up new technologies after very little exposure to them, days usually, rather than weeks or months.

I've added up the hours spent in a CS degree program on purely CS classes; it's around 650 hours total. That's it. If it were back to back 8 hour days, it'd only take about 16 weeks of 8 hour days 5 days a week. Obviously that'd be a rough sell, but it's not impossible.

This is 19-25 weeks, I'm guessing 1 or 2 hour 'days', which is around 100 to 250 hours of 'training'. That's just under half - about the equivalent of a 2 year college. More than enough time to fit in the basics of theories as well as actual application, though they may not get some of the higher level specifics like graphics or compiler design.

So it seems reasonable to me, and I've been doing this for 2 decades now with my fancy college learning.