BDD: It's about value

I was drawn to Behavior Driven Development the moment I was pointed toward Behat not just for the automation but because it systematized and gave me a vocabulary for some things I already did pretty well. It let me teach some of those skills instead of just using them. At DrupalCon Amsterdam, Behat and Mink architect Konstantin Kudryashov gave a whole new dimension to that. His presentation, Doing Behaviour-Driven Development with Behat, was a straightforward, well-sequenced, and insightful explanation about why automation is so not the point, even though he began by writing automation tools.

Many Drupal shops have found themselves battered in the bizarre project management triangle, where clients push for more and more features within fixed budget often within wildly unrealistic timelines. Based on research conducted by Inviqa, where he works as the BDD Practice Manager, as well as a now-classic study by the Standish group showing that for all that pressure for more and more features, nearly 50% are never used, he makes the following claim:

Your clients don’t care about your scope. Your clients don’t care about their budget. They care about their business. And the reason they try to get so many features on a finite budget is that they don’t believe that you care about their business.

They don’t know how what you do will help them, yet they take a chance. But because they don’t know and they don’t believe, when they come to you they’re really saying, “I don’t know if you can help me or not, but I’m willing to spend this amount of money to see if you can. And I don’t know which of the things you do will really make a difference, so I want everything I can get in hopes that something will help."

The talk focuses on quality vs. quantity in software development and how BDD methodology and tools are intended to drive a quality-first development process.

The research was interesting, for sure, but for me, not entirely necessary. I already had a big case of confirmation bias.

I entered web development in the mid-90s, the flat-file days before Content Management Systems were popular. I had pretty okay Unix system administration experience and was developing standards-oriented HTML 2.0 skills, but at heart I was we now call a “content strategist.” My formal, pre-technical background is in literature and education, so it makes a certain amount of sense that I entered the tech world content-first.

From the very beginning of the Web, it seemed clear to me that the point of sites was to communicate. There are significant technical considerations about how to support the communication, but ultimately the goals and missions should guide what is built, when it’s built and how it’s constructed.

I emphasized content above all back then, but after my first update of a large site from Drupal 4.7 to 5, I started to explain to new clients that Drupal is free as in puppies, and you’d better plan a maintenance budget. They would need to either trust or understand the kind of ongoing consequences of technical choices. You don’t just take home a new web site, you have to care for it, feed it, make arrangements for its care when you plan to go out of town. Despite good intentions, I had implemented my share of those unused features for a variety of reasons (all of which made sense at the time).

Still, it wasn’t until the late 00s, when I started to interact with Drupal agencies, that I realized achieving business goals and improving organizational communication weren’t even goals for some projects. As Drupal rescue projects began to come in, I realized that if Drupal was free as in puppies, then clients needed to steer clear of the puppy mills. I was feeling that pressure, especially when bidding on a project, to promise more and more features for a site without regard to the consequences - for delivery now and for maintenance later.

At one point, I toyed with addressing that pressure by joining a larger team. I remember interviewing for a job with a Drupal agency that involved immersive on-site consulting with clients. I asked during that interview how much they interfaced with their clients’ business process. My interviewer responded, “We don’t have the luxury of understanding our clients’ business.” I appreciated the honesty and withdrew my application.

I knew the value I offered my client was less about technical prowess and more about listening well to their needs and desires, then translating those into deliverables. That’s what the Behavior Driven Development methodology helps me with - ways to keep the whole team focused so they work on what really matters.

* This image is from a great blog write-up by agile coach Dave Moran about where unused features come from, features which lead to considerable baggage as people implement, maintain, and sometimes even port features which are never used.