Behavior Driven Development

College was misleading.  There, we were led to believe that the customer (professor) was technical and actually knew in advance exactly what they wanted.  The requirements were chiseled in stone, two months out, and there were test suites waiting to tell us if our work was "correct."  

In reality, the customer is generally an expert at something other than technology.  They generally don't think in terms of edge cases and they certainly don't write tests for us in advance to ensure that we cover them.  Even if they were, business is a fast-paced and evolving thing, what is seen to be a competitive advantage today may be a liability tomorrow.  The only constant is change.

Agile teams understand this and structure their approach to delivery with this in mind.  Rather than attempt to conceive, build, and deliver the perfect application in one fell swoop, they steadily deliver work in small, usable chunks, every few weeks.  The customer is encouraged to think in terms of what functionality will deliver the maximum benefit to the business and prioritize the pipeline of work accordingly.

This tends to reduce feature creep, but it doesn't address the generally poor communication between the project's various stakeholders and the resultantly poor-quality deliverable:

This is where BDD comes in.  It bakes quality into the process by smoothing communication between stakeholders.  Here is how we're practicing it on my current project:

• The Business Analyst works with the Customer to determine what it is that the business is trying to accomplish.

• The BA, QA, and Developer sit down and have a discussion. The QA focuses on flushing out the bounds of the system and edge cases.  The Dev focuses on implementation and brings up potential technical hurdles.  The Business Analyst answers questions, ensuring that the customer's high-level business needs are met.  This is the software equivalent of 'measure twice, cut once.'  Many times, poorly conceived requirements are eliminated before even reaching development  

The outcome of this meeting is a document that will function as a specification, test suite, and living system documentation. Here is a simple Login Story written in Given, When, Then format:

Login Story

Scenario:  Basic Login

Given I am a basic user

When I login

Then I should see the basic homepage

Scenario:  Administrative Login

Given I am an administrative user

When I login

Then I should see the administrative homepage

Scenario:  Invalid Login

Given I am not a valid user

When I login

Then I should see the error page

• The developer(s) now get to work on the implementation of the story.  The preceding conversation will have given them a high-level understanding of what the business wants from the system as well as clearly codified acceptance criteria.  Their high-level perspective prevents them from diving down a tangential rabbit-hole while the non-prescriptive nature of the spec provides for creative latitude in implementation.

• The feature complete, the QA and Developer pair on functional test implementation.  The developer brings technical expertise, while the QA brings an understanding of the system as a whole.  They "fix", to each step in their story, code that will exercise the new system features.

• Next comes what we call the "desk check." The pair calls the BA over and demonstrates the completed feature by running the functional test.  The BA may give an initial sign-off there or they may notice something incorrect  or incomplete.  In the case of the former, the dev will move on to a new story; in the latter, the dev will correct the behavior of the system, update the functional test to "lock-in" the additional requirement, and re-submit for approval.  This process has the benefit that the developer has not yet mentally context-switched to a different piece of work and so they will be able to more quickly rectify the problem than if they worked on the fix weeks later after it gets logged as a bug.

• When, at some later date, the business inevitably decides to change a system requirement, the test will fail, as the system is no longer performing as expected.  The story is then modified to reflect the new behavior.  Using our previous example:

(Original)

Scenario:  Invalid Login

Given I am not a valid user

When I login

Then I should see the error page

(New)

Scenario:  Invalid Login

Given I am not a valid user

When I login

Then I should see an error message on the login page

In this way, we say that the story functions as a living document.  As the behavior of the system evolves over time, the team is forced to evolve the documentation in parallel.

Why Agile?

I am primarily interested in problem solving. Some problems are technical in nature, others are social. I like that the Agile approach to software development embraces human nature and leverages it to the benefit of both the business and it's employees.


An Example:
In the interest of limiting distractions, many companies build cube farms.  They tuck each of their employees away in their own little box and assume that this will make them more productive.  This is a technical solution to a social problem.  If we were horses, blinders might work, but we're not.  We are social monkeys.  We need social interaction and mental stimulation, so we then turn to facebook or the web when we get lonely or bored.  The company then employs website filtering in an attempt to keep the employees on task.  This results in frustration as employees are prevented from doing legitimate research as a result of the filter algorithm's false positive's.  As time progresses, the employee grows to resent their overlord.  They build relatively weak social relationships with their co-workers and they feel no sense of loss when they quit.


Now let's look at the Agile (XP) alternative, Pair-Programming.  Two people, two keyboards, two mice, one computer.  The entire workday is a combination of conversation and problem-solving.  It's anything but boring; "Let's do this", "You're an idiot", "Holy crap, you're right!"  It is difficult to surf the web when you're in the midst of a conversation.  Over the course of a few days worth of shared coffee breaks, lunches, and late night beers, you develop some surprisingly deep friendships.  Over the course of a project, the team becomes a family.  Pair-Programming is a social solution to a set of social problems.  It reinforces positive behaviors without impugning the dignity of the employee.  On top of that, the resulting code has 40% fewer bugs, requires fewer total hours to deliver and two people now understand the same code base, so you're covered if one of them wanders in front of a bus.  Everyone lives happily ever after.