Another study, Investigating the viability of mental models held by novice programmers:

This paper describes an investigation into the viability of mental models used by novice programmers at the end of a first year Java programming course. The qualitative findings identify the range of mental models of value and reference assignment held by the participants. The quantitative analysis reveals that approximately one third of students held non-viable mental models of value assignment and only 17% of students held a viable mental model of reference assignment. Further, in terms of a comparison between the participants’ mental models and their performance in in-course assessments and final examination, it was found that students with viable mental models performed significantly better than those with non-viable models. These findings are used to propose a more “constructivist” approach to teaching programming based on the integration of “cognitive conflict” and program visualisation.

Also, see later research from the same authors of the Sheep vs Goats study (which was never actually published, to be clear). Their last and most recent study on this topic from 2009 is Meta-analysis of the effect of consistency on success in early learning of programming (pdf).

A test was designed that apparently examined a student’s knowledge of assignment and sequence before a first course in programming but in fact was designed to capture their reasoning strategies. An experiment found two distinct populations of students: one could build and consistently apply a mental model of program execution; the other appeared either unable to build a model or to apply one consistently. The first group performed very much better in their end-of-course examination than the second in terms of success or failure. The test does not very accurately predict levels of performance, but by combining the result of six replications of the experiment, five in UK and one in Australia, we show that consistency does have a strong effect on success in early learning to program — but background programming experience, on the other hand, has little or no effect.

Yes, there’s a pretty famous paper online designed to more or less determine “Who is cut out to be a programmer.”

A cognitive study of early learning of programming – Prof Richard Bornat, Dr. Ray Adams

All teachers of programming find that their results display a ‘double
hump’. It is as if there are two populations: those who can [program],
and those who cannot [program], each with its own independent bell
curve.

Almost all research into programming teaching and learning have
concentrated on teaching: change the language, change the application
area, use an IDE and work on motivation. None of it works, and the
double hump persists.

We have a test which picks out the population
that can program, before the course begins. We can pick apart the
double hump. You probably don’t believe this, but you will after you
hear the talk. We don’t know exactly how/why it works, but we have
some good theories.

Here’s a blog post by Jeff Atwood that interprets the results and puts some things into context.

Despite the enormous changes which have taken place since electronic
computing was invented in the 1950s, some things remain stubbornly the
same. In particular, most people can’t learn to program: between 30%
and 60% of every university computer science department’s intake fail
the first programming course.

Experienced teachers are weary but never
oblivious of this fact; brighteyed beginners who believe that the old
ones must have been doing it wrong learn the truth from bitter
experience; and so it has been for almost two generations, ever since
the subject began in the 1960s.

Anyone can be a programmer. Consider how easily people grasp spreadsheets. Consider how readily Alan Kay introduces children to programming by means of experiment and exploration in a programmable environment.

People may study success in college-level courses and conclude “some people aren’t fit to learn programming”. However, such a conclusion severely oversteps the bounds of the observed evidence. How much failure could instead be attributed to how the programming is taught (too abstract?), or which style of programming is taught (too imperative?), or the programming environment (compilation, no immediate feedback?).

It is well understood that people grasp abstractions most readily after they’ve already worked with multiple concrete instances – i.e. that we cannot learn something until we almost already know it. Starting with the abstract, therefore, is an entirely foolish way to teach programming. Many people who stumble over premisconceived “mental models” would thrive if taught in a more concrete environment with real-time feedback (e.g. as in the Kahn Academy for CS) then encouraged to climb the ladder of abstraction when they are ready for it. Learnable Programming is a recent essay by Bret Victor draws attention to unnecessary environmental challenges programmers face in learning.

In some cases, it is the students that fail their classes. Intellectual laziness and willful ignorance will exist in any large group of humans. Smart folk are no exception, as anyone who has argued with a brilliant crank can attest. But, especially for programming and maths, it is often the classes that are failing the students.

Maybe this is anecdotal, but when I taught intro programming to a few hundred liberal arts students, I found no such “double hump”.
It seemed to me they were all quite capable, though some worked harder than others,
and a very few tried to bluff their way through.

A lot has to do with how it is taught.

A lot also has to do with desire – some don’t find programming the least bit interesting.
But even so, they can learn it if they give it an honest effort.

When I started out it was common to sit an “aptitude test” before you got a programming job. There were not so many computer science graduates, so it was common to recruit from other disciplines.

The tests were similar to what you see on IQ tests (what’s the next number in the sequence, etc.).

The anecdotal evidence was that while not everyone who passed the test became a good programmer, no one who failed the test but was hired for other reasons ever became a good programmer.

Sadly HR drones did not understand these tests (and failed when they took them!), so recruitment these days depends on things HR drones understand — good college, communication and suit wearing skills.

This is pretty much the reason large IT departments have lots of people who are great at PowerPoint shows and very few good programmers.

To those citing Dehnadi and Bornat’s double-hump or goats-vs-sheep study, it’s worthwhile to check out Mental Models and Programming Aptitude by Caspersen et al (2007) in which they attempt to replicate it:

Predicting the success of students participating in introductory
programming courses has been an active research area for more than 25
years. Until recently, no variables or tests have had any significant
predictive power. However, Dehnadi and Bornat claim to have found a
simple test for programming aptitude to cleanly separate programming
sheep from non-programming goats. We briefly present their theory and
test instrument.

We have repeated their test in our local context in order to verify
and perhaps generalise their findings, but we could not show that the
test predicts students’ success in our introductory program-ming
course.

Based on this failure of the test instrument, we discuss various
explanations for our differing results and suggest a research method
from which it may be possible to generalise local results in this
area. Furthermore, we discuss and criticize Dehnadi and Bornat’s
programming aptitude test and devise alternative test instruments.

One can make studies about abstraction capacities, or other useful knowledge, but the definition of programming is unclear, and I think the quote is irrelevant, because there are opposite ways to look at programming:

The first kind: Programming languages are (or should be) some kind of human language made to describe a task for the computer to execute, so everyone who talks should be able to program. It’s called scripting, BASIC, the typesetting system TeX, etc… The language or the system doesn’t matter, it’s the way their creators and people looked at it: “Dear program/computer, please print my name”, rather than “Get me space the size of eleven chars, then give me the adress of this space, then let me store it, then enter eleven characters into this memory which you can take out of my keyboard buffer (but don’t forget to clean it, etc.”

In this case it’s clear that the study would rather be “Not every language can be assimilated quickly?”.

On the other hand, programming languages are just a way to describe how a computer works or how it should work, how it should be ‘connected’ if you think of 1950s computers. Therefore the programmer can’t do anything, even if he ‘speaks’ the programming language perfectly, if his/her intelligence can’t reach this abstraction level where you see bytes beeing stored in memory, strings as pointers, etc., and then go back to earth to link it to the problem. Therefore not every human can program (in assembly language…).

Apart from this, you will need all qualities required to work and produce something: know very well what you want, make it easy for others to understand/complete/review, focus on your objectives, etc… But just like an architect, a writer, a musician, a prostit..aehh prothesist, etc.

But most humans have good abstractions capacities, especially children. Some German schools are teaching Haskell to pre-teens (programming languages like Pascal or Delphi are beeing taught in every German school).

So I would say the question is very hard to answer, and any answer (or study) is likely to be irrelevant.

You will find a very brief analysis of how people learn programming in the article Teach Yourself Programming in Ten Years by Peter Norvig. He seems to think there is no born programmer.

Many years ago I did several courses that included military leadership theory. Part of the theory was that there exists a leadership continuum, from those who are natural leaders to those who couldn’t lead a dog on a leash. The idea was that people were distributed on this leadership continuum in a bell curve, with most people being somewhere between the two extremes. Apart from the few at the far extreme “couldn’t lead a dog” end almost everyone could be taught the art of leadership. The amount of effort required to turn someone into a leader depended on where they sat on the continuum.

I suspect programming has a similar continuum and a similar distribution. There’ll be those that just get it effortlessly, and those that could never get it if their lives depended on it. But they’re the few at the tail of the bell curve. Most people sit between those extremes on the continuum. They can learn to program but the effort required to teach them will depend on where on the continuum they sit.

I’m not sure it’s just programming. I saw the same sort of phenomenon with people simply learning to use computers. Back in college I was a lab assistant in a lab that hosted a computer literacy for seniors class.

Within two weeks I could identify those who would get it and those who wouldn’t with basically 100% accuracy. You either accepted that this is the way the computer works or you beat your head against it for the whole class. There was no middle ground. (The fact that it was a seniors class meant we had a lot of head-beaters which made the pattern much more obvious.)