Is TDD Dead Part 3 Transcript Concise Version : Fast Feedback and Quality Assurance

Kent said that decisions involving TDD were about trade-offs: "In some ideal world we would have instant, infallible feedback about our programming decisions", "every key stroke that I make, if the code is ready to deploy, it would just instantly deploy." But that ideal is impossible at the moment so the question is how far do we back off from that. He went to enumerate several constraints in the trade-off.

• Frequency: how rapidly do we want our feedback ?
• Fidelity: how accurate do we want the red/green signal to be?
• Overhead: how much are we prepared to pay?
• Lifespan: how long is this software going to be around, which is a probability as well as time.

Those four are the constraints he thinks we need to compare. "My personal goal is just to understand the set of trade-offs by articulating them to people who are prepared to tear my ideas apart in a constructive way"

Fowler outlined three things that we can look at, to get feedback on:

1. Is the software doing something useful for the user of the software?
2. Have I broken anything? 
3. Is my code-base healthy? This so I can continue to build things quickly.

David introduced the topic that TDD's success had led to a neglect of QA. The other issue is that to understand trade-offs you have to understand the costs, all the talk of TDD has been on the benefits. This neglect of costs is why people cannot comprehend that there is such a thing as test-induced damage. The trade-off continuum is true of other things. Consider the cost of reliability: going from 99% to 99.999% is exponentially more expensive than getting to 99%. We must also consider criticality. High reliability is important for space shuttles and pacemakers, but wrong for an exploratory web site. The rule of not writing a line of production code without a test doesn't fit in with trade-offs around criticality.

David agreed that it was good to mindfully trade-off QA for initial speed, but some have taken programmer testing too far and don't see the value of exploratory testing. Your tests may be green but when it's in production users do things you don't expect.

David says that worst of all is when developers are not part of of customer service. Many programmers don't want to be on-call because it's drudgery, but it's also a feedback loop. Code with green tests can be a plateau that's below where you want to be. "The on-call is the feedback loop that teaches you what tests you didn't write." As soon as you think you don't make mistakes any more, that's a mistake, and you stop growing. He'd rather pay the price of catching that early with a phone call at 2am.