The Circular Perspective of BDD 3
A few weeks ago, Brian Ford was in my office and we were discussing BDD and how we can make this process even easier for our clients to understand… much less our own internal staff. With all concepts, each person has their own idea about what it is, why it is important, regardless of whether or not it’s accurate. This can cause some people to not find a good need for some practices.
During our discussion, Brian grabbed one of my whiteboard markers and drew diagrams to explain how he saw BDD vary from TDD. He has since posted an article on his blog titled, what’s it worth to me, and discusses his circular view of Behavior-Driven Developent and the importance of using Dialogue to evolve shared meaning.
Enjoying the content? Be sure to subscribe to my RSS feed.
BDD doesn’t exist. It’s not real.
Just to clarify, the diagram distinguishes a more traditional, linear view of development from TDD/BDD. It does not distinguish, in my mind, TDD from BDD.
The problem we often encounter is that clients have an entrenched view of development as a linear process similar to building something like a house. Once a room is finished, the owner doesn’t expect the builder to say, “now we’re going to refactor this.”
But with software development, we’ve found that when clients do not understand refactoring, it becomes a significant hurdle to communicating about the status of the software, especially for clients that are highly feature-driven.
House-building isn’t even that linear—especially if the owner is involved in the entire process. Framed walls can and are pulled apart and moved, doors are moved, flooring can be ripped up and replaced with something different, etc etc.
I had success explaining to a client once that what they were expecting (no-refactoring from feature to feature) was like building a house one room at a time - start to finish. Frontroom pour the foundation, frame it, sheetrock it, paint, carpet, roof, siding. Bedroom- pour, frame, sheetrock, etc etc…