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,669
  • 3
  • 21
  • 35
  • 3
    Can you provide a source or definition for "traditional software development"? Who used it and what was the context? – Thomas Owens Jul 18 '17 at 16:39
  • I saw it in a video. Maybe I can reword the question. – johnny Jul 18 '17 at 16:40
  • 2
    My point is, there are lots of other methods for building software, and not all are mutually exclusive. Rapid Application Development, Unified Process, Extreme Programming, PSP/TSP, Scrum, TDD, BDD, FDD, DDD, model-driven development. Some can be paired together nicely. Others can't. I'm not aware of a single, common "traditional software development" that could be referred to. – Thomas Owens Jul 18 '17 at 16:43
  • Possible duplicate of [Relation between BDD and TDD](https://softwareengineering.stackexchange.com/questions/111837/relation-between-bdd-and-tdd): "BDD adds a cycle around the TDD cycle..." – gnat Jul 18 '17 at 16:45
  • I did not think it was gnat but I will look again. – johnny Jul 18 '17 at 16:45
  • BDD is not simply 'talking in business language' [have you read this?](https://en.wikipedia.org/wiki/Behavior-driven_development) – JimmyJames Jul 18 '17 at 16:45
  • 1
    @JimmyJames I will look. Probably have seen it. I suppose I am just hung up on everyone I read talking about developers as people that have no idea what a customer really wants. And that you have to have special meetings to figure that out, as if that was a secret way no one ever knew about - Asking the client what they mean when they say xyz. – johnny Jul 18 '17 at 16:51
  • Gah. It looks like they are using "traditional" to mean "waterfall" or the opposite of agile. I...don't like that. – Thomas Owens Jul 18 '17 at 17:04
  • 4
    @johnny: It's not that developers have no idea what the customer wants... it's that the customer has no idea what they want. The way you solve that is by using *iterative* practices, where you build small prototypes, get feedback, make suggestions, modify the prototype, and repeat this process until the prototype matches the customer's expectations. – Robert Harvey Jul 18 '17 at 18:40
  • 4
    As to your word definitions, I strongly suspect that the commentators are using "traditional software development" as a euphemism for "not my latest and greatest software development flavor of the week," in which case you're chasing a red herring. – Robert Harvey Jul 18 '17 at 18:42
  • 2
    Dan North is using "traditional software development" as a contrast to "agile software development" and has no corollary with behavior driven development. You can do BDD with waterfall or agile. BDD is a style of writing tests, essentially. – Greg Burghardt Jul 18 '17 at 19:34
  • 2
    @johnny Generally even the business doesn't really know what they want or at least can't explain it well. Most of the time, in my experience, you have to build something and get people to tell you what's wrong with it. For most developers, figuring out the requirements is both the most difficult task and most important for predicting success. If this is easy for you, that's awesome. [It's possible you underestimate how hard this is for others because you are highly-skilled or that you overestimate your ability in this area.](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) – JimmyJames Jul 18 '17 at 19:39
  • I never said it was easy. I only know you have to do it. If I said easy I lied. – johnny Jul 18 '17 at 21:25
  • @GregBurghardt: You can't do BDD with waterfall. In waterfall, the architecture documents drive the development. In BDD, the tests (ehm, I mean behavioral examples) drive the development. That's what *BDD* means. The most important letter of that acronym is the *middle* "D". Also, in waterfall testing comes last, whereas in BDD tests (ehm, I mean behavioral examples) *must* come first, since *they* are the driver for development. You cannot drive development with something that doesn't exist. It is *not* about writing tests *first*, that is a *consequence* of the tests being the driver. – Jörg W Mittag Jul 18 '17 at 22:10
  • @JörgWMittag *"You can't do BDD with waterfall."* Yes, you can!TM The definition of the desired behavior comes from the *requirements documentation*. The main differnce between *iterative developement* and *waterfall* is that with the latter the *requirements documentation* is not expected to change. – Timothy Truckle Jul 19 '17 at 07:33
  • 1
    @TimothyTruckle: Exactly. Not that I'm a fan of waterfall, but in my previous project, which was waterfall, as soon as I got the requirements document I wrote the functional tests in Cucumber before writing any other code. If you really wanted to be a stickler for BDD, the mass of documentation up front would be the Cucumber tests. They would represent use cases, rather than "user stories". – Greg Burghardt Jul 19 '17 at 11:37
  • @johnny: Are you asking what the difference is between "traditional software development" and "agile development"? The two terms you want us to compare are not comparable. – Greg Burghardt Jul 19 '17 at 11:42
  • @GregBurghardt That is probably part of my problem. I will try to learn more. – johnny Jul 19 '17 at 14:38
  • @TimothyTruckle: IIRC, waterfall specifies a specific order of the phases; in particular, testing comes very late. You cannot drive the development process with tests if tests come only when the development process is largely over. – Jörg W Mittag Jul 28 '17 at 18:43
  • @JörgWMittag *"IIRC, waterfall specifies a specific order of the phases; in particular, testing comes very late."* My interpretation is that *at the end* of the test phase of the waterfall model all (automated) test must exist and have been executed. As far as I see the waterfall model does *not forbid* to write automated tests earlier... – Timothy Truckle Jul 28 '17 at 18:49

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
  • 2