Google don't do Test Driven Development, so I don't see why I should either
Countless software devs

We live in a world where people love to apply quick fix solutions to problems. Lose 10kg in 2 weeks! No cash until payday? Borrow £100 at 30000% APR! We crave these simple solutions, and deeply want to believe that they can make our lives better.

It's a good idea to look at the context we are in, then work on a way to change the system that governs that context. Once we understand the system we can then look at adopting tools to help us.

For both of the examples I gave in the introduction a good question would be: What's your food intake and exercise like? How are you spending your money currently? But people don't do this. They are far more interested in the next miracle fix. Sadly in the IT world we are just as susceptible to quickly grabbing a new tool that worked for someone else, then either blindly going with it or quitting in absolute disgust.

We can improve the process we use to select tools to remedy our problems. The key to this is to stop only focusing on how a tool works and its benefits and start by asking what problem the tool solves. The first two parts are important, but useless without knowing if it's solving a problem you have.

I suggest we use this checklist when considering any new tool or practice:

  • What problem does it solve?
  • How does it work?
  • What are the benefits?
  • Will this work in my context?

A lot of people have a strong reaction to BDD and Cucumber so let's use that as an example. We'll use a shortened summary of the checklist items then consider a recommendation for two different personas.

Cucumber checklist summary

Cucumber solves a number of problems often seen in software development where misunderstandings are rife. In particular it solves the problem of the business speaking a different domain language from the development team by asking them to collaborate on acceptance tests together in a simple natural language script.

Its benefits include living documentation, automated acceptance tests, and encouraging an outside in view of software development.

Is Cucumber right for Angus?

Our first persona will be Angus. Angus had an idea for a mobile app and hired two people he trusts to help him build it. Angus has heard great things about Cucumber at conferences and wants to try it out with his team.

Angus doesn't have a major problem with miscommunication within his team. If he tries Cucumber he'll probably decide that he doesn't like "the extra layer of indirection" Cucumber introduces. As the readers of the tests are all technical, he could get the same benefit from just writing outside-in integration tests in the testing framework he's already using.

Angus should look for other methods, or invent his own, that can give him some of the other benefits that Cucumber brings.

Is Cucumber right for Bruce?

Bruce works for a medium sized digital agency who specialise in online shopping sites for a wide variety of clients. His customers like to run discount campaigns during different seasons. Currently he gets the client to write the pricing rules down in an email which he turns into code.

The product owner for Bruce's project is not part of the team. By using Cucumber's acceptance criteria with the client he could quickly discover problems with his understanding of the pricing code and also open up other conversations with his client.

Bruce should look into adopting Cucumber.

Context is king

When you hear about a tool you need to look at the problem it solves, the other benefits it brings and consider if this makes sense in your own context. The misapplication of tools leads to pessimism and waste. We should be optimistic about new tools, but grounded in our current context. Context is king.