Do You Want to Save $50,000 per Developer per Year?

A number of case studies have shown that a typical developer spends 30% to 40% of their time fixing bugs. Specification by Example/BDD is designed to prevent those bugs and give you back all of that time. If an average developer earns $150,000 annually in salary and benefits, 30% of their time is $50,000 – per developer, per year.

I like to talk about two kinds of bugs – Little-B bugs and Big-B Bugs.

are the ones where the code doesn’t do what the developer intended – the text entry box isn’t large enough, or sorting doesn’t work, or the wrong data is returned by a query.

are the ones where the code does exactly what the developer intended – it just isn’t what the customer wanted. These are immensely costly; your developers may have spent two or three sprints writing really good, clean, highly maintainable code that does the wrong thing!

Specification by Example prevents Big-B Bugs by changing the way that Product Owners, Business Analysts, Developers, and QAs communicate. SBE says that all requirements must include concrete examples; concrete examples make it much easier to discuss the requirements, to understand them, and to find other important examples. This makes it much, much easier to avoid creating Big-B Bugs.

SBE also makes it easy for the QA team to deliver automated tests to the developers before the developers finish coding; this helps prevent both Big-B Bugs and Little-B Bugs.

As the accounting department, I want late bills to be charged a penalty\” is a nice user story, but not acceptable as an SBE requirement. Here is an SBE requirement:

Specification by Example prevents Big-B Bugs by changing the way that Product Owners, Business Analysts, Developers, and QAs communicate. SBE says that all requirements must include concrete examples; concrete examples make it much easier to discuss the requirements, to understand them, and to find other important examples. This makes it much, much easier to avoid creating Big-B Bugs.

SBE also makes it easy for the QA team to deliver automated tests to the developers before the developers finish coding; this helps prevent both Big-B Bugs and Little-B Bugs.

For example, “As the accounting department, I want late bills to be charged a penalty” is a nice user story, but not acceptable as an SBE requirement. Here is an SBE requirement:

Scenario Outline: Late bills will be charged a penalty on a sliding scale Given an active customer account And a bill that is days past due When the bill is paid Then a penalty will be charged

Examples:

Writing requirements this way makes it really easy for everyone to communicate clearly; this prevents Big-B Bugs. The QA team can automate this requirement and deliver it to the developers in-sprint; this makes it easy to verify that there are no Little-B bugs.

Implementing SBE/BDD well can save $50,000 per developer per year — how much of that do you want?