Not in-depth across the whole set; I picked apart one or two before coming to the conclusion that there was something inherently flawed in the whole approach of modeling study of the phenomenon after the protocol for medical intervention. That won't work; you can't do a double-blind study of TDD vs placebo. It's a conceptual tool, and as such requires knowledge and skill.
"Treating" a convenience sample of students with a 2-hour training session and trying to measure "performance" afterwards isn't going to yield much insight into what goes on in the mind of a seasoned programmer who's used TDD exclusively for a while. In my experience, the effects of such practice most definitely carry over to programming where you don't even try to apply TDD.
What convinced me to try TDD was a combination of naivete and desperation. What kept me at it was the undeniable, if entirely anecdotal, feeling of wrestling back control over the code I wrote. It's a more complex set of techniques than just "writing the test first", but it's hard to tease them apart and introduce them into your coding independently of each other.
Part of it is a commitment to evolving a program in very small steps, at every step having a whole program that works. Part of it is a set of instincts for refactoring, so that this program also has just as much "design" (if such a thing could be quantified) as is strictly necessary for the time being. Part of it is a habit of framing the next capability as a tiny experiment, with the test being the experimental protocol, and focusing your mind on just those interactions within the code that are relevant. Part of it is a way of "slow debugging", of not jumping to conclusions when you encounter unexpected behaviour but drilling down into what made the behaviour surprising, and revising your mental model of the program.
Put like that it's clear that to "simply write unit tests", for instance to check a box in a process model, cannot possibly give you the same benefits as practicing the above interrelated set of skills. But it's also clear that it requires more involved guidance than "just write the test first". You can pick up a lot of it on your own, to be sure, just like many people can learn (say) guitar on their own and get all sorts of nuance in technique from focused practice.
But you have to love doing it, and that's not something easily picked up in academic studies.
I'm a big fan of TDD, but I quit reading this article the second my eyes came across "IBM System Sciences Institute" and the chart that accompanies it.
It's normal to experience emotions related to what happens at work. It's called "being human". And dealing with emotions - putting words on them, accepting them and moving on - is a key skill and a part of growing up.
What varies, in my experience, is whether and how much it is acceptable to discuss (and thus process) these emotions in the workplace itself. Being able to say "I'm sad / angry / joyful about X" makes a world of difference.
Once I became aware of that I started being able to remedy it. To start with I actively sought and encouraged discussions of the emotional components of whatever work I was a part of. Retrospectives were a great way of having a structured framework for these discussions (as opposed to giving the impression that I wanted to psychoanalyze my colleagues or vice versa).
After a while I noticed, too, that management in some places actively preferred the dehumanizing effect of making emotions undiscussable, because it afforded easier control over people. I started avoiding these places and selecting jobs that accepted and expected me to behave as a human adult.
I'm all too aware of these many citations. A few years ago, I went to the trouble of chasing down most of the papers and books, and evaluating how well each of them supported the claim. To put it mildly, I was underwhelmed.
However, I haven't (entirely) changed my mind about TDD and similar practices. I do still believe it pays to strive to write only excellent code that is easy to reason about. I like to think that I now have stronger and better thought out reasons to believe that.
I'd put the cost of defects claim in the category "not even wrong".
If someone made quantified claims about "the number of minutes of life lost to smoking one cigarette" I would refuse to take them seriously: I would argue that the health risk from smoking is more complex than that and can't be reduced to such a linear calculation.
This talk about "the cost of a defect" has the same characteristics. I don't mean the above argument by analogy to be convincing in and of itself, and I've written more extensively about my thinking e.g. here: https://plus.google.com/u/1/+LaurentBossavit/posts/8tB2RQoHQ...
But it's a large topic that quite possibly deserve a book of its own.
As for the history of software engineering, it's pretty much the same - to do it properly would entail writing a book, pretty much, and I didn't want to do it on WP unless I could do it properly.
I'm disappointed to see a book aimed at "professional" developers continue to spread outdated and debunked information, such as the NIST "study" adduced as evidence for the imperative necessity of "defect cost containment". See my post on the topic: https://plus.google.com/+LaurentBossavit/posts/8QLBPXA9miZ
I'll add my voice to those that have already stated such a book shouldn't start by assuming the SDLC as a reference model: it embodies too many of those outdated assumptions. More in that vein in my own book http://leanpub.com/leprechauns
"Though it promises robot carers for an ageing population, it also forecasts huge numbers of jobs being wiped out: up to 35% of all workers in the UK and 47% of those in the US"
...not only are those forecasts not from the cited source (they're from an Oxford study), they're also not credible:
Also, "manual testing" is a slightly unfortunate monicker for the activity we are discussing. It is bound to generate some degree of incomprehension or even hostility on the part of some people, for no foreseeable benefit. "Testing" will do. It is something you do with your head primarily, your hands being involved to pretty much the same degree that they are in programming (and we don't usually call that "manual programming").
As far as I can tell France universally uses "Flow A" (get your card back first, then your cash). When I started using ATMs, in the late 80s, I remember that "Flow A" and "Flow B" were about equally common, then in a relatively short span of time all the banks switched to A.
It surprises me, reading about it now, that it could be different in any other part of the world. That Flow A is the correct solution is not obvious, but it should be obvious to anyone who's studied human behavior and human error, which should be anyone involved in the design of ATMs. The form of "goal fixation" Jenny mentions is a very common pattern in human errors.
> The idea of this is not "try to break the robot"
Think of it this way. If you want to learn what constitutes strong chess play, will you learn best from playing a) yourself or b) a much stronger player?
Having a "collaborative" exchange with a chatbot is of the same strength as playing chess with yourself, for the purposes of investigating what "thinking" consists of.
The Turing Test is useful precisely when we are trying to "break the bot" as you put it; in fact, when the bot is pitted against a real human, who in that contest plays the role of the chess master.
Saying that Eugene Goostman "passed the Turing Test" is like crowning me World Chess Champion, based on the amazing record of beating 70% of a random sample of six year olds.
> "if you ran into this robot in real life
You wouldn't ever "run into" Eugene Goostman in real life, because it lacks the kind of generalist problem solving ability that would allow it to insert itself into any "real life" situation - an ability that even six year olds possess. It literally couldn't even get out the gate.