managementWikipedia says that Bug Driven Development (BDD) is an anti-pattern. Raja Shankar Kolluru perfectly explains why. However, Florian Rappl argues that it’s not. Ben Winding believes that it’s better than TDD. In simple words, BDD is kind of like trying to build a plane while it’s flying, based on passenger complaints. Nobody builds planes like that (well, maybe Boeing and Airbus). However, a software team that practices BDD might demonstrate higher productivity.
A software team does BDD if it follows one simple principle: Every piece of work is formulated as a complaint.
It started in 2002, by Mozilla:
Every code change in the Mozilla codebase is made as part of a “fix” for a uniquely numbered “bug.” Though it commonly has a pejorative connotation, in the Mozilla Project the term bug is used to refer to any filed request for modification in the software, be it an actual defect, an enhancement, or a change in functionality.
If you listen to Mozilla’s advice, you won’t have feature requests, or questions, or tasks in your issue tracking system. Only bug reports. They may sound like “The wing is on fire!”—a perfect complaint—or “A plane doesn’t have a jacuzzi!”—a perfect feature request in the form of a complaint. Questions may also look like complaints: “It is unclear how to fasten the belt.” Whether they are coming from testers or customers, the format is the same: “I don’t like it.”
The primary benefit that BDD can give to a project is noise reduction. I can think of two reasons for that:
Complaints, due to their rather aggressive nature, require their authors to provide strong arguments to back them up. They must think twice before submitting a ticket that accuses the codebase of being broken or imperfect. They must be specific and precise. No noise.
Similarly, programmers must convince a complainant that the problem is resolved. They can’t close the ticket with just a text answer. They need to demonstrate a reasonably significant contribution to the codebase. No noise.
A good complaint identifies a flaw in something tangible. A good resolution of a good complaint is a patch to that tangible something. Obviously, in a software project, the source code is what is tangible.
In a disciplined team, every ticket is a bug report that addresses a flaw in the source code. Every bug report leads to a patch—a contribution to the source code. No noise. The team is focused and demonstrates the best possible productivity.
BDD also has a major drawback. It may be hard to train the team to use it. The adoption of BDD may require a change of their mindset. They must switch from noise-makers to flaw-finders.
Jeff Atwood, in his blog post about complaint-driven development, explains it from a business point of view. He suggests that instead of implementing what you believe is right, it’s better to give your customers a rough draft and let them complain. You’re most often wrong about what they’ll actually complain about. The more they complain, the better you listen, the bigger the value you deliver.
