Behaviour Driven Development - NLP Based Software Development

, Agile, BDD, Behaviour Driven Development, Neuro Linguistic Programming, NLP

NLP or Neuro-Linguistic Programming is a term I have heard a lot over recent years. as someone who is a big believer in self-development and positivity it is a very important term to me. I was particularly intrigued then to read about BDD Wikipedia - Behaviour Driven Development which is an extensions of TDD where instead of focussing on the code we take a more stakeholder centric view of what we are writing. Put one way, TDD made us think about what code we where writing, BDD makes us think about why we are writing it.

In traditional TDD we take the idea of a requirement and write it for acceptance in the form of a statement:

As a someone, I want to do something, so that I can perform this action.

For a simple example, if I were writing a piece of accounting code for an internal system:

As a payroll clerk, I want to be able to retrieve an employee’s salary, so that I can see how much money they need to be paid.

This as an initial idea (and still a widely used one) is brilliant. It takes an example use case and makes us as developers think of what tests we can write to then write code for. So here one could write a test like:

TestMethod SalaryRetrieved(employee testEmployee) {
  AssertNotEquals(employee.getSalary(), null);

I know this test is a little “woolly”  to say the least but it is only to highlight the idea that we merely write the test to check that the code does its job. The essence of TDD is that my code will be written to pass the test, do its job and nothing more. Here for example, it will get the salary of the employee, nothing more (such as their tax code, NI number etc).

With BDD we change our view to that of scenarios. Our acceptance criteria now become a series of scenarios which allow us a more agile approach by providing specific examples that define correctly the scope of the requirements for the feature, which in turn leads to a better solution and a better estimation of creating the solution. In keeping with the TDD “As a, I want to, So that” setup BDD has the setup “Given a, when I do, Then I get”. So our example above becomes “Given an employee with a salary of $50000, when I ask to get their  salary, then it will be correctly retrieved”.

BDD here builds upon the NLP idea of saying specifically what you want to affirm a goal. In their many works, Richard Bandler and John Grinder suggested that instead of treating or diagnosisng a lot of psychotherapy patients you rather need to change the model they work with, and this idea can be applied to more general (and less serious issues) as well. For example, many people want to “not be fat”. This is suggested as the wrong way to think about your goal. Constantly going to the gym everyday and thinking “I am going so that I don’t have to be fat” includes the thought in the background “because I am fat”. Instead you should focus on “being thin or healthy; “I am going to the gym because I am fit and healthy” because this associates to yourself and your self image the idea of you being fit and healthy (see the self fulfilling prophecy). This all sounds a bit new age, but lets play a little game. Below are 2 instructions, which I want you to follow and then we can see what results you get. Just remember or write down the first thing that pops into your head.

  1. Don’t think of a duck.
  2. Think of a goose.

I will place good money that your first thoughts were a duck and a goose. By trying not to do/be something, you are positioning and associating yourself with respect to the thing you don’t want to be.

Despite this being a generally great trick to use, it is extremely useful here through  BDD because by specifying more exactly some scenarios of what we want, we can make sure it does this. A test can be designed to check something doesn’t fail, or it can be designed to make something do something. Instead of our test checking that we do retrieve a salary we can check that given a certain employee we do retrieve a specific thing. It’s a subtle difference but can make all the difference in defining what you actually want your software to do.

Share on Twitter, Facebook, Google+
Prev Next