So, I work in a web development company and I'm the only iOS developer there.

The company has decided that we would like to start using BDD (Behaviour Driven Development) in order to reduce dev costs, speed up communication etc...

We're going on a training course next week so everyone can come away and do brilliant BDD.

I just received the email...



Riiiiight... so it's going to be a web dev training week.

They do have an email to let them know so I'll drop them a line

This should be fun. lol

Is that similar to Agile?

In applying for Web Designer roles, I've heard the phrase Agile Methodology bandied around - still don't fully understand it, but it appears to be built around short bursts of task-driven development, breaking the project down into smaller chunks, is that right?

I've not heard of Behaviour Driven Development (BDD) though.

Agile is the whole development process.

Instead of creating a concrete spec for the entire app and sticking rigidly to it it revolves around looking a week or so ahead and planning that and then doing the same.

It allows flexibility in the software and stuff...

Or something like that anyway.

BDD is like TDD. TDD is a method of actually programming where instead of ploughing in and starting code you look at what is needed and write a test that will check that requirement. The test fails (as you haven't written the code yet) so you then write the minimum amount of code needed to pass the test. Then you add another test. It fails, so you write a bit more code. Rinse. Repeat. ... App. The tests are normally in the form of "When I add a new recipe to my catalog the label showing the number of recipes increments by one".

BDD is essentially the same except it ties in the logical side of the developer with the fluffy side of the client. The tests are normally in the form of, "When I add press the "Add Recipe" button and leave the name field blank and then press the "Save" button I will see an error message with the text "A recipe must have a name".

Yes, that's my usual summation whenever I've read up on it!
No, I think I know what you mean - we used to call it "making it up as you go along!"

LOL! Yes, that's my take on what it is.

Essentially, you know all that stuff about Use Cases and Actors and Roles and Specs and things like that that you learnt at uni.

Well this is just software development without doing all of that.

So far as I can make out:

TDD allows you to pretend things are going well while not actually making anything useful
BDD is TDD with pictures and spreadsheets
Agile is the usual chaos but standing up and with cool T-shirts

Basically, they're all ways of coping with the fact that the specification wasn't done properly

No TDD is actually really good if used with a proper spec.

It's there to cover your own back. All the code you have has tests to show that it works.

If you refactor something and all the tests still pass then you know everything is fine. If you refactor something and a test fails then you know where and why it is going wrong.

Agile, yeah, it's just an excuse not to have a spec.

TDD can be good if used with a good spec.

More often though, it seems to be a diversion exercise so that, despite not making what the customer wanted, success can be proved.

The tests should be written from the spec, before any code has been written, that should be the same with any decent methodology.

Frequently the spec is a moving target, especially for a long complex project, because you can't force the world to stand still for your convenience.

Agile just means a method that can change easily, the one you described is more like Scrum for short deliverable milestones.

BDD (business or behaviour), TDD etc are good but they get banded around as a buzzword now with a lot of people using the phrase without actually applying it. In my experience it only works with some clients but for internal projects it's a useful thing to have.

I sometimes think that all these buzz words are total BS. It sounds like they want the ability to change direction with the software.


Sent from my iPad using Tapatalk HD

To a point yes, less rigid dev processes such as scrum (short weekly planning meetings, short repeated delivery cycles for features) and TDD (prrof of quality of what you deliver) are ways to do this. Requirements and clients/projects don't stand still or they get stagnant and outdated. Better deliver in phases to keep up to date. We do that with most projects is deliver a phase 1 then update/add functionality later on so the core requirements are met and then the client is familiar with the product when they get the additions.

You wouldn't give someone flight sim 2013 and after a day expect them to be as proficient as someone who has had flight sim 2012 3 months and now has a some new features to learn.

To a point of using it in job specs/business descriptions, absolutely. If a company isn't practicing any form of agile dev in favour of traditional waterfall it shows very quickly

That is much more practical. When I was programming I did it modular so I could get each module working before combining.

While that's definitely true of the technical spec, the functional spec should rarely, if ever, require changing.

IME, the spec is a moving target because

• the pink shirts who make the original spec don't know what they're talking about and will promise the moon on a stick
• the bean counters have no clue about how long stuff takes to produce
• Management think they can improve project outcomes by increasing the volume of shouting, the sh*ttiness of emails and the frequency of meetings
• nobody involves any technical people until after the contract is signed
• nobody involves the actual users until primary UAT