(A-Z) Driven (Development|Design)

cellfish — Tue, 13 Jan 2009 22:24:00 GMT

In Swedish there is a saying that translates to something like "a loved child is known by many names". Probably there is an English saying for that to but what do I know. Anyway I was thinking the other day about the fact that BDD is known as "TDD done right" and EDD is known to be "a better name for TDD". We also have ATDD, UGDD, DDD and a lot of other double D's. So I saw a challenge in this... Coming up with double D's for the complete (English) alphabet. And I did... Not all of them are that serious but I definitely could find myself using all of them in a conversation. Here is the list - feel free to help me add more...

Also I feel I must comment on the Development/Design thing. What is the difference? Development things are things used during development all the time. Design things are things done early and/or at a high level when designing the application and should typically include no details on implementation.

BDD and DDD

cellfish — Wed, 09 Apr 2008 01:07:00 GMT

I've previously written about BDD (in Swedish) and maybe I should translate some of those articles since I've now decided to start writing in English. Anyhow, last night I had the chance to listen to Dan North on the topic: How does DDD and BDD relate? This was the first time I've listened to Dan live and I must say I was surprised - in a good way.

First of all he have that special British humor we tend to like in Sweden. Secondly he was very pragmatic in his thoughts about different theories and how (and why) they should be implemented. Another thing I like since agile evangelists (not saying Dan is an evangelist but...) tend to be less pragmatic than what is healthy for them and their theories.

First part was about describing DDD. I must confess that I've had some troubles understanding what all the fuzz has been all about when it comes to DDD since domain driven design always have been quite obvious to me. That was until this evening. Dan pointed out that there are a lot more domains to consider than even the traditional DDD-evangelists talk about and I think this was an important point. As was the point that some of the domains might be technology related. One interesting trick of the trade I learned where: If some domain is not interesting to one person - it is a domain interesting to someone else. Example: End users don't care about implementation platform - hence it is a domain important to someone else.

Then started a short presentation of BDD. And now it got interesting since I've had a few discussions with other people and I'm a firm believer that BDD is TDD done right. I still agree that TDD is a bad name for Example Driven Development or whatever you want to call it and I have always felt a little uncomfortable with how BDD is often presented, i.e. as something new. I'd rather like to see BDD as a coaching aid in order to explain TDD. But since TDD is such a bad name I'm happy to use BDD since it better describes how I think TDD should be practiced. The good thing is that I don't feel Dan said anything contradicting my beliefs. If anything the opposite, I feel my view on BDD is the same as Dan's which at least makes me feel good when I talk to people about BDD.

So what was the conclusion of the presentation? Well, DDD is about design and DDD helps you design the vocabulary you should use. BDD helps you develop the correct behavior. Together they are a better tool than each of them alone.

Being Cellfish : DDD

(A-Z) Driven (Development|Design)

BDD and DDD