Sunday, January 15, 2012

Is BDD a Mistake?

Sometimes life just gets in the way of blogging.  And sometimes I am not sure what topic to blog about.

Well I happen to spend some time this weekend reading all of the controversial posts on the Agile Austin forum.  The controversy was a multi-threaded monster.  However, the first post I read by Scott Bellware caught my attention.  Scott wrote a post about how BDD has essentially destroyed software development.

Here are a couple of excerpts.  And I am going to do my best to try not to take these excerpts out of context.

"You can't add quality to a product by adding tests."

Well I must say that I completed agree with that statement.  Tests serve as a net to potentially catch misses in quality, but in isolation a test does not inherently add quality.

"It also bears repeating that every automated test is a form of
coupling, and every coupling is an anchor chained around the neck of
productivity."

So if I understand his point with this comment, Mr. Bellware is saying that implementing tests slow developers down.  I can see where that might be partially true; however, from my experiencing by writing tests developers think more thoroughly about the software they are building.  In the past three years as an automation engineer, I truly learned the power of TDD.  Writing test firsts showed key failures in my logic early.  I am not a developer, but I certainly saw a great advantage to writing tests against my code.

Here is a doozy.

"The problem - especially after so many years of degradation of the
Agile Development message - is that most coders are still driven by
the superstition that "quality" and "testing" are inseparable. This is
the software development world's Flat Earth superstition."

Definitely several points in this statement.  My main thought is that quality is the act of doing the absolute best work you can do in order to add value for someone.  I think doing your best should include testing, but they can be separate concerns.  Unfortunately I have not met many developers that ooze quality with every line of code they write.


"BDD is fascinating technology, and that's why it's popular. In and of
itself, BDD as a practice violates every design principle that
matters."

Wow!  Did he really say "BDD violates every design principle that matters."  I admit that I am not fully versed on principles of design, but Wow!

 I tried introducing Cucumber as a test automation practice.  What I loved about BDD, Cucumber, is that it started a dialogue around what value a feature provides.  I also liked the fact that it was extremely easy to take text and instantly turn it into a failing test.  What I did not realize was how hard it would be to get people on board with Cucumber.  

"Quality Built-In is how quality is created. It's a matter
of designing the right thing and not making mistakes."

So I guess as a tester I think this is a "Flat Earth superstition".  Fundamentally I disagree with this statement, because the unfortunate truth is EVERYBODY makes MISTAKES.

"BDD - in the Cucumber/Gherkin/GWT sense - is knowable as a mistake.
It's a mistake from a methodological perspective. It's a mistake from
a process perspective. It's a mistake from a usability perspective.
It's a mistake from a structural design perspective. And it's a
mistake from a team and organization perspective. That we don't see
these mistakes is a testament to the immaturity of our industry and
the perpetual susceptibility of its participants to unfortunate
fashion trends."

Again Wow!  Scott is saying that BDD has zero value.  I am going to respectfully disagree.  I will agree that it is a huge struggle to figure out the most efficient process for using BDD.  I have certainly made mistakes.  And I would admittedly state that I have not fully studied the idiosyncrasies of BDD.  I believe as a tester and automation engineer, Cucumber helps us find where quality was NOT built in.



"It's heart-breaking (as are many missed opportunities in software
development) to see the extent of harm wrought by BDD in the general
programmer population. It's heart-breaking to see that programmers
still have very little interest in the meaning of quality and it's
fantastic potential for massive increases in productivity."



So to me the above statements gets to the heart of Scott's forum post and the underlying concern really has nothing to do with BDD.  "Very little interest in the meaning of quality" is the most telling part of the above statement.  I know that in their hearts software developers care about quality, but I think there are many other influences besides BDD that impact quality.  The hard core fact is that mistakes are made.


Here are a couple of links to more material to support Scott's premise,  Oslo presentation and a Lonestar Ruby Conference.  These presentations provoke additional thought.


I will conclude by stating that Scott really sparked my two brain cells to work over time.  Was introducing BDD a mistake?  I still do not think so.  Did I make mistakes with respect to process and my personal education on BDD?  Yes!


I doubt Scott Bellware will ever read this post, but I must thank him for truly making me think.  And I think there is so much more to learn with respect to quality.  I plan to pay more attention to see if BDD is truly a mistake.