My criticism of this and similar articles is that in this article we're back in the mythical Widget factory where programmers are given requirements to create o

My criticism of this and similar articles is that in this article we're back in the mythical Widget factory where programmers are given requirements to create or improve widgets. In my real world experience, the largest amount of work necessary to work in this manner is in step 1 and 2, where the business requirements need nailing down. But this is also where business stakeholders disappear. It's better or worse at different companies, and what I'll highlight here is the worst case, but even in the best places this still happens to a lesser degree: Once the story is written, stakeholders become uninterested, they consider further design is an implementation detail and not their job, they become "busy" when you try to ask questions. This is work that overall the business doesn't prioritise and doesn't properly give everyone time to do, so stakeholders dodge their responsibility (or don't realise it is their responsibility) and developers are left to make things up. But a developer left to their own devices will often think of the implementation designs first, and then think about the tests. The more experienced developers will keep edge cases in mind, but they are still edge cases relating to the design, not the interface. To have an entire process around iterating around the edges, is something it's difficult to convince people the value of. So you come away from an article like this feeling warm and fuzzy but any attempts to implement such a process crumbles against hard reality. And then the author dismisses such criticism by saying "well that's not TDD". Well sure, he coined the term, so he can choose to define it, but it's not helpful for anyone looking to practice TDD if everything they try gets dismissed by a No True Scotsman argument.