random ruby thoughts from a random web developer

A (not-so) long time ago, when the world was young and ASP.NET web components were cool, my colleagues pushed me into unit testing in with NUnit and jsUnit. When I switched to ruby, Test::Unit made me feel right at home with the familiar syntax and assertion syntax.

Until recently I slipped in webrat as a selenium abstraction in my rails integration tests, while trying to battle the constant slippery of client-side errors the project was experiencing.

One thing lead to another, and soon I replaced the built-in integration tests with cucumber, and removed the tests of a simple gem in favor of specs. Before you know it, I was purchasing the beta of the rspec book, reading about the strange and sometimes awkward syntax of my new tools.

From a programmer’s perspective it was not that different than the xUnit frameworks I knew. Sure, things were called differently, I was “shoulding” and not asserting, and the MVC concerns were split in a slightly different way. A matter of taste, I was thinking, not a big deal. Keeping an eye on twitter, many people were stating the same. I was not really paying attention to the native language descriptions I was acked to provide, considering them redundant at best.

It actually “hit” me when I was reading my next purchacse, The art of agile development. I was doing it wrong. Well, not really wrong, but rather missing the point. I was doing TDD with the BDD tools.

So what is the real difference?

wikipedia nails it:

Behavior Driven Development (or BDD) is an Agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally conceived in 2003 by Dan North as a response to Test Driven Development, and has evolved over the last few years.

BDD, while carrying all the benefits of TDD has certain (less than) subtle differences. It is far more aligned with the Agile values, and extends the concept of testing to force developers in actually communicating with them customers. With TDD, you aim at verifying that your code actually works. With BDD, you are communicating with the rest of the team, providing human readable artifacts, which document the logic of your implementation.

It took me a while to figure out this. BDD is not about the tools, it is about the process. The sole usage of RSpec, Cucumber or any other BDD framework out there does not make you behavior driven. It is all about the communication, which the agile evangelists love to brag about. And I consider it a bold attempt to resolve one of the most complex problems in our industry – project failures due to failed communication.

Okay then, let’s do it! All the cool kids are doing it, right? OK, I am installing cucumber…

Hold your horses. Let’s figure if you really need it. Remember: To go for behaviour driven development model, you should first qualify for the test-driven one. But is it so? And why TDD is not mainstream? Why don’t we study it in the universities?

The often overlooked fact is that many companies and teams don’t care about stability and lack of bugs. In many cases, rightfully so, since this is not going to make the software successful. We all know examples where buggy, slow software dominates the market because of good marketing and sales, or because of the brilliant idea it implements. Or just because of pure luck. This is pretty common, in fact. Maybe it applies to you too? Maybe you are working as a “bolt” in a company developing enterprise product, where the sales decisions are made by exectutives puffing fat cigars driven by commission rate contracts. And maybe the main business model is based on charging dearly for bugfixes and consulting fees? If this is so, you can safely ignore this article. You should not try to improve the quality of your work, anyway.

Adopting BDD is even harder. It faces the problems of its predecessor along with the obstacles that prevent Agile from becoming mainstream. What BDD has to do with Agile? A lot. Actually, BDD makes sense only in Agile environment.

The Agile Problem

Many people perceive Agile as yet another “methodology”. Nothing can be further from the truth, actually. Agile is just a term that wraps a set of values, that the team shares. If your team shares them, the practices such as XP, Scrum and so on come naturally, because they are just tools for reaching the goals that matter. Without that, XP is a torture, and scrum is just one huge masquarade, where people pretend to listen to each others yada-yadas.

Of course, agile is a buzzword nowadays. It is interesting to figure out how many of the employees in the companies who proclaim themselves agile have actually read this:

The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the things on the right, we value the things on the left more.

A hidden message that has long evaded me here – the first line in the manifesto is a value itself. A person with an “Agile” mindset proactively searches for better ways of developing software.

Unfortunately, the Agile manifesto has a problem with many software producers’ personal values. Try it for yourself – answer honestly what best describes your motivation for doing software. Maybe

• You are a sociopath and you hate dealing with people. Being a programmer gives you the freedom not to interact with them nasty human beings on a daily basis;
• Or you are all for the money, and there is nothing that can put more cash on the table;
• Or you have always wanted to be a famous artist/rockstar, but failed at playing the guitar;
• Or It just happened, while you were wondering what to do with your life;
• Or maybe you consider yourself a brainiac, seeking to resolve complex problems?

None of the above is that bad in fact, we are all humans. But if these are the reasons for you doing software, then your personal values are in a direct conflict with the agile mindset where working software, collaborating with customers and interacting with the individuals should be the main motivation.

In the context of BDD, any attempts to adopt it without first making sure that the agile mindset is clearly present in your team does not make much sense. Sure, you can write specs, and elaborate cucumber features – but this won’t be more than a fancier TDD (or, best case, a single person BDD – not that bad as an excercise!). BDD really shines when it comes to team collaboration efforts.

Well, but how exactly does BDD will help me communicate with the rest of the team?

By forcing you to speak their language, and by keeping you focused on resolving the problems that matter instead of floating away in activies that have no business value for the project. As Ryan Bates says

Even though I’m a developer, I still like writing Cucumber stories (instead of Ruby) because it helps me put on the Customer hat.

Unfortunately, the technical aspect of bringing the natural language definitions to the rest of the team is left as an excercise to the reader. I would like to give you a suggestion – use Continuous Integration. You have one, right? It will constantly update and visualise the business cases you’re working on, the ones that are being resolved, what is pending, what is broken, and what is in progress – either by emails or by generated web reports. Given that, the rest of the team should be able to easily check what are you doing currently, and how’s it going.

But, the customers/managers won’t bother reading my crap!

Perfectly valid point, especially valid for non-agile teams. Unfortunately there are two, sometimes overlapping reasons for that.

First of all, them business people are too busy. Oh yes, they are. But if they are too busy to pay attention to the project they payed money for, then it is obviously a project that should not have been started in the first place. You need a domain expert to verify your work, and you need a stakeholder to be up-to date and to make decisions on priorities and release schedule.

Second problem is that specs are too techincal, and often do not make any sense to non-developer. Guess what? You are the one that provided sloppy natural language descriptions. And I do feel your pain at this point, because us developers historically suck badly at explaining our actions. You should not give up on this though. Read the output of the spec results with the rest of the team. Ask for feedback frequently; what makes sense? is the explanation too vague? Aren’t the specs for some internal code parts too “technical”? Hard to understand specs may be sign that your design differs from the domain.

“The Revolution Will Not Be Televised”. And BDD won’t be mainstream.

A BDD is a practice that makes sense in the right environment. Remember that the agile environment relies heavily on each individual personal virtues, and agile teams are hard to find, build and maintain. And forcing agile is not known to work.