First, it's great to see such a wonderfully thought out article on the selling of programming tools to programmers. I've been doing this stuff for like 25 years now and I've seen a lot of fads and tools come and go.
I would like to try and not group TDD and BDD as similar things because in my eye they really aren't: they both provide very different approaches to solving a problem. If you were to simply cover TDD then I would agree with you that it is something that focuses on programming and the programmer and operates within that area of software engineering.
BDD, on the other hand, really has little to do with telling a programmer how to test their code or even how to program. About the only thing BDD "requires" a programmer to do is implement the Behavior described. There are a lot of ways to do this, but BDD adds a lot of other cool things too (like you can verify the requirements provided too).
So, when you mention that "The 'good' programmers all do things this certain way" and see BDD as a tool forcing that. Well, I don't think that is the case.
The funny thing is that BDD isn't even a new thing because it relies on scenarios. It is very similar to Use Cases with one minor, but important, difference: there was no standardization on Use Cases (Writing Effective Use Cases by Alistair Cockburn is a great book). Cockburn left the way scenarios are written open to the engineers whereas BDD provides a simple language, Gherkin, that can be used consistently across different tools (Cucumber, Behat, Specflow are a few examples).
So, from that aspect, this isn't some new "fad" that is being sold to developers. It is just a few changes to a well known tool: Use Case.
I would like to try and not group TDD and BDD as similar things because in my eye they really aren't: they both provide very different approaches to solving a problem. If you were to simply cover TDD then I would agree with you that it is something that focuses on programming and the programmer and operates within that area of software engineering.
BDD, on the other hand, really has little to do with telling a programmer how to test their code or even how to program. About the only thing BDD "requires" a programmer to do is implement the Behavior described. There are a lot of ways to do this, but BDD adds a lot of other cool things too (like you can verify the requirements provided too).
So, when you mention that "The 'good' programmers all do things this certain way" and see BDD as a tool forcing that. Well, I don't think that is the case.
The funny thing is that BDD isn't even a new thing because it relies on scenarios. It is very similar to Use Cases with one minor, but important, difference: there was no standardization on Use Cases (Writing Effective Use Cases by Alistair Cockburn is a great book). Cockburn left the way scenarios are written open to the engineers whereas BDD provides a simple language, Gherkin, that can be used consistently across different tools (Cucumber, Behat, Specflow are a few examples).
So, from that aspect, this isn't some new "fad" that is being sold to developers. It is just a few changes to a well known tool: Use Case.