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)