The argument that often gets trotted out when I ask developers to think about increasing their level of automated unit test coverage is that you can have buggy code even with 100% of the code covered.

They're absolutely right, of course. But is that a reason to leave code uncovered by your unit tests? It does sound rather like those people who argue that, because science can't prove anything completely, there's no value in approaching something scientifically (like alternative medicine, for example.)

Programmatic Testing:  A style of software testing where tests are executed without human interaction.

When I say "this test can be automated", I don't mean a computer can magically replace a sapient process to create a useful test.  All test design and methodology is devised using a sapient processes (obviously).  However, testcase generation, data generation, test execution, results analysis, etc, can often be done without human interaction.  This has been described using terms like: "Automated Testing, "Test Automation", etc.  Among some of the more vocal people in the testing community, these terms are considered confusing,  inaccurate, harmful, or just a cover up for what is actually a non-scripted test

In my initial post No More Iterations I mentioned that estimating was a factor in the change we were making. Specifically:

• Story size was difficult to estimate and kept crossing iteration boundaries.
• The programmers really didn't see the value of estimating stuff they weren't familiar with and in our planning poker session gave out lots of ? and 100 cards.
• We were spending to much time researching the time it would take to fix a bug that we weren't going to work on for several weeks.
  

After reading posts by David Anderson and Amit Rathore I started to examine why we were estimating, how much time we were spending at it, the psychic cost, and the results. The results were not encouraging.

I’m ready for people to take a look at a chapter. It’s actually the second chapter of the book. The introduction, covering prerequisites, the general plan of the book, its goals, what “Cocoa” is, etc.—that will probably be written last.But to orient yourselves:I assume you know Ruby, but nothing about Objective-C, Cocoa, or building apps [...]