In 2014 David Heinemeier Hansson published a blog post, "TDD is dead. Long live testing". Hanson - the creator of Ruby on Rails - has great standing in the software community, and so his blog post created a firestorm. In response, Martin Fowler arranged for a series of debates between Hansson and Kent Beck - the creator of Test-Driven Development (TDD). (Note: "BDD" and "ATDD" are not the same as TDD.)
Whenever I talk to Agile coaches, they advocate TDD, as if it is a given for Agile teams. Yet when I talk to programmers, I either find great eagerness or extreme apprehension. It has always seemed to me that TDD resonates really well with some programmers, but is a nadir for others. The reactions belong to either of two polar opposites. Why is that?
TDD-enamored friends of mine, some who work for companies like Netflix and Amazon, tell me that if I don't like TDD, then I have not given it a chance: that if I really stick with it, I will eventually like it. Is it that I will eventually see the light? Or is it like this: that if I keep hitting my head against a wall, then I will eventually become numb and get used to the pain?
After a great deal of reflection, I finally realized that TDD is an inherently bottom-up, inductive process; but I prefer a top-down, reductive process. That's how I think, and I am not alone.
The polarity of opinions about TDD is not unlike the division in the sciences between the experimentalists and the theorists: they don't understand each other, because they think and work differently. Experimentalists want to try things to see what happens, and think about the implications later. Theorists want to first think, and then when they have a theory, they ask the experimentalists to test it. The theorists are top-down and reductive. The experimentalists are bottom-up and inductive.
That's just like the personality difference between TDD people and non-TDD people! And this means that TDD is not for everyone, but it is for some people. It means that one's affinity for TDD is a matter of personality. It means that if someone is not cut out for TDD, they never will be - no matter how long they try it for.
And it means that if you don't like TDD, then not using TDD does not mean you are not Agile, or not doing things right. It means you are being true to yourself.
The problem is, there is no accepted Agile approach for people who don't like TDD - the top-down thinkers. We certainly don't want an old school big-design-up-front approach, because we know that big designs up front are wrong, and that process does not work well. So what then?
Progressive Driven Development (PDD) is an Agile process for top-down programmers - the reductive thinkers, the ones who like to think things through before they start coding. The ones who like to diagram, and think in terms of algorithms, and only after they have first thought and designed their approach, finally turn to the keyboard.