This doesn't really apply to TDD in any way that can't be applied to other methods. This article is just about how too many choices cause paralysis when making a decision.

That's a pretty deceptive title. It's friism's conclusion that TDD makes you work harder, not The Economist's. I'm not saying I disagree with the notion, but half the reason I read the article was to find out why The Economist might be talking about TDD.

That's why the interpretation is in parentheses.

Yeah, the conondrum of how to sum up the relevance of an article in a headline. I didn't mean to deceive, merely to give an edge to original titel.

That's because breaking an abstract task into concrete steps is a task in itself. So, people with an abstract task have more to do than those who just have concrete steps.

Often the most difficult task, I would say.

Interestingly, I had never noticed the similarity of TDD and GTD -- David Allen's Getting Things Done methodology, where you basically break up abstract problems and needs into physical tasks that can be checked off a to-do list.

The question is, can you integrate RSpec with OmniFocus?

Actually it explains why breaking up tasks into smaller tasks makes you more efficient. TDD is just one way to do this.

You're absolutely right.

I still think the article is uniquely relevant to TDD however, in that TDD explicitly mandates chopping tasks into small chunks and this research seems to validate that approach.

I think you may be introducing some bias to your conclusions. The article could also be seen as concluding that giving someone abstract tasks is less efficient then giving someone a concrete task...the former leaves a lot open to decide, the latter makes your problem space much smaller so I'm not sure if they are fair to compare ( the former does actually involve quite a but more work ). It's like sitting down with someone and you say "Write a ten page story." instead of "Write a ten page story about a green monster living at the top of a snowy mountain." People given the second choice will almost always start writing immediately, and those given the former will sit around and think for hours about what to write. And when you look at the conclusions of the article like this, you can make a strong counter-point against TDD and that is simply that you can't get much more abstract then by being asked to write tests for code and functionality that doesn't even exist yet. (Note: I'm a fan of TDD, but for the million other reasons)

The article is about abstract vs concrete, not big vs small.

FWIW, psychological research (into the area of manamagent quality initiatives, self-help techniques, etc) has shown that adoption of any system works because of the attention applied to the situation, and I'd stretch that to include code, too.

Terrible. This is not science. I do not at all agree with the conclusions. There is only a correlation, but the cause/effect relationship they infer is shady at best.