BDD workshop completed

Yesterday I met with a few former colleagues for the last time. We've met for a few hours three times discussing how to start with TDD and then continuing with BDD. We have had several long discussion on why you benefit from using BDD and how to overcome a number of common mistakes made by BDD novices. It has been vary interesting and I want to share a few of the things we've talked about.

For example we talked about the economics of BDD. The very first time you start using BDD you'll probably spend a lot of extra time to complete your first release as compared to not using BDD (and probably not writing any unit tests either). So how do you motivate this extra cost? First of all I think we can all agree that the behavior driven code will have less defects. This means less time you have to work for free (to fix defects) and you can also focus more on your next project making more money there since you're less interrupted with bugs in the old code. Defects will also typically be found earlier and defects found early when you're still working on the code are fixed faster (i.e. less cost). Second, when the customer wants new features you will probably be able to add new features more quickly with all the test in place than without them. But you still ask for the same money as before so you make a larger profit on all additions. All in all tis should make your software more profitable over time.

Other than economic incitements I think the fact that you as a developer will know if a change breaks the code and not just guess is a great improvement on working conditions. And the fact that you know you're releasing high quality code (instead of hoping you do that) should be enough for every developer to jump on the BDD train...

We've also had long discussion on how to test drive GUIs but I'll cover that again in a future post coming in a few days.