0

What is the difference between so called Traditional Software Development (TSD) and Behavior Driven Development (BDD)?

I've seen a lot of different development methods that teach developers to talk in business language. Yet, to me, all of this seems like common sense.

How could the developer(s) ever think they could build anything without asking the folks with the money what they want and with examples?

I do not get the difference between the two. Everything I have ever worked on required me to understand things from the Business' perspective ("Ubiquitous Language"). I did not see this specific question on SE. I don't even know what "Traditional" means because it is axiomatic to me.

Can someone please tell me what the difference between the two are?

Edit: I've seen so many that it is difficult to keep track, but here is one video I saw. I hesitate to post one video from one person because I have seen more than one person. But this one uses the explicit term Traditional.

https://www.youtube.com/watch?v=JwLhR9RI3ew
https://blog.smartbear.com/software-quality/deliberate-application-testing-in-agile-with-dan-north/

Searching for it like this also makes usage of the term:

dan north "traditional software development"

johnny
  • 3,679

1 Answers1

3

I see 2 questions here:

1 - What is the difference between traditional development and BDD?

In my experience when someone tries to explain the concepts behind BDD to someone and they use the term traditional software development they often refer to the waterfall method. This can be seen in your second link in the sentence

Traditional software development was linear, starting with development, then testing, and finally operations.

Whether this is a correct comparison could be argued since most developers already use some sort of Agile approach since a long time.

2 - How could developers build anything without asking BA's what they want with examples?

A lot of developers (both programmers as well as testers) I have worked with simply ask the requirements from the business, but are not actually discussing and even challenging those same requirements. The latter is what BDD is all about. The outcome of those discussions should be some good examples of which all parties have the same understanding.

Eddie Terlouw
  • 46