Response article: Behavior Driven Development by s0937917

In response to ”Behaviour Driven Development: Bridging the gap between stakeholders and designers” by s0937917 [1]

1. Introduction

The author writes about the ideas of Behavior-Driven Development (BDD) in relation to the communication divide that is often perceived between developers and other stakeholders of a project, with the other stakeholders mainly referring to the clients. This communication divide can lead to internal problems in translating a customer description into something more akin to a technical specification. A somewhat hyperbolic, albeit clear analogy, is that of the tree swing, used by the author as an example of what he or she means. These specification problems can then supposedly be mitigated by the use of BDD in any given project.

2. Points of disagreement 

As much as I agree with this premise, there are certain points made in the article that I do not necessarily agree with. There are definitely upsides of BDD, a methodology with promising characteristics, such as the similarities between the user stories and the resulting implementation. It tries to mimic the business language used to describe the characteristics of the product in question. Considering that the tests serve as the basis for the implementation, the need for modeling languages such as UML, or other forms of explicit modeling and documentation, is diminished.

However, my disagreement is with the assertion that it solves the communication problems between the client and the engineers. An example used in the article was: ”as a service subscriber I want to click on the poster for movie X and is launched in the same window”, out of which several questions arose. Now, using a BDD framework might help make the translation of the user story into its subsequent test much clearer than, say, using plain JUnit. I fail, however, to understand how the use of BDD solves the problems arising from the initial user story.

These problems, or questions, were of the following nature:

  • ”If the user clicks “open in new tab” should the browser just launch the video player or the same page with the player embedded to allow deep linking?”
  • ”If the user had started watching the movie earlier closed the browser in the middle, should the movie start over or continue from where it was left off?”

These are aspects directly related to the functionality of the application. The author goes on to say that they can block development and lead to developers or program managers having to contact the clients and wait for an answer. The main problems lies with the assertion that this is somehow not desirable. I will argue that it is, and furthermore, that it is one of the cornerstones of agile development [2]. The clients need to be regularly involved in the development process, and it is imperative that both the engineers and the clients understand this from day one. BDD is not a replacement for iterative development and continuous communication. The necessity is made even clearer considering the fact that we know the least about the requirements in the beginning stages of a project [3].

Another consideration is of course the technical expertise of the client. I would argue that the communication is even more important in projects with non-technical clients, who will not necessarily review the code base. In such circumstance, BDD seems promising in its ability to effectively translate business requirements into test cases, but again, this differs from getting those business requirements right in the first place. The business requirements are always courtesy of the client and therefore it would be dangerous to make any assumptions with regards to the questions that arose following the initial user story given as an example above. BDD cannot answer the question if the application should allow streaming of multiple movies at once, only the client can.

Client or customer feedback is a fundamental part of getting things right in an agile project. An interesting approach is that of Complaint-Driven Development [4], somewhat humorously outlined in a Coding Horror blog post. Such an approach explicitly emphasizes the developer-client relationship and the never-ending feedback cycle between the stakeholders.

Lastly, the author highlights another interesting issue in the ways that developers think. Engineers and testers think in code. Most often, clients do not. Dealing with this problems is arguably the single most important characteristic of BDD. It helps developers understand requirements in a different manner, a manner that is tighter coupled with the user story. With that in mind, I agree with some of the conclusions made about BDD in the original article, regardless of my critique of its capabilities in this brief response.

3. Conclusion

It certainly does seem to push for better code standards, meaning that the relation between the business description and the code is not arbitrary. They both follow the pattern of: Given some condition X—> When I do Y —> Z happens. If this is inherently better than any other method is difficult to say, but it certainly makes the code clear, concise and thus, arguably, easier to maintain. It does not, however, solve the communication problem, nor is it even intended to in my mind. It does overcome the translation problem, but the requirements must still be defined, and as clients, we do not always know what we want right from the start.




[3] A. Clarke, ”Software Engineering Process and Management”, University of Edinburgh, 2013/2014