Behavior Driven Development: Impact on Developers

Behavior Driven Development (BDD) represents a fundamental change to many software developers. Most of us work by understanding the requirement,  coding a solution, then testing it. BDD takes the first step much further. Not only will we understand the requirement, but also how the solution will be accepted. Adding to the uncertainty, adopting BDD usually means that the developers are also getting used to Agile. BDD is a great complement to Agile because it improves the definition of being 'done' that accompanies the conclusion of each iteration (or sprint).

BDD saves the developer time because it focuses attention on only those edge cases that are important to acceptance. The solution can be developed faster, with greater quality, when the developer knows which edge cases are needed. When these edge cases are not anticipated two possible problems occur: (1) the code has to be 'hacked', changed in ways that are outside the solutions design, to accomodate edge cases, or (2) the code is over-engineered to handle edge cases that are not really needed for acceptance.

BDD also reduces the amount of time spent on optimizations. Developers love optimizing their code; thinking up increasingly clever ways to squeeze features out of the fewest lines of elegant readable code. When it's known that certain features have to perform well to be accepted, then the time spent on optimization can be more targeted. 

Finally, developers have to learn how to use new tools, like Cucumber. Cucumber enables the creation of specifications that become executable acceptance tests. Many developers struggle with the idea that they must also write the code to facilitate the test, along with the code for the solution. Over time, developing code this way forces a developer to challenge assumptions much sooner. And the automated tests expose more problems early, when a solution has to be re-factored.