Over the last two months I've thought endless times about starting a series of posts on Behavior Driven Development (BDD). Starting sometimes late last year I began reading up on BDD and trying to wrap my head around what it was, how it was different then TDD, and why I should care. I started to hear a quiet buzz from a number of people in the community regarding BDD, so I figured at the very least I should give it a look. Right around this time Brian Donahue was rounding up speakers for the Philly .NET Code Camp. To make a long story short Brian and I decided to do a joint presentation on BDD.

As I prepared for our presentation I read as much material as I could online about BDD. Some of the sources of information that stuck in my head include:

• http://dannorth.net/introducing-bdd
• http://behaviour-driven.org/
• http://video.google.com/videoplay?docid=8135690990081075324

While I think I've gotten much closer to understanding what BDD is about, I think there is still a good bit of discussion that needs to happen in the respective communities that are looking to adopt BDD. Although I've been too busy lately to follow any of the mailing lists I'm subscribed to, I do drop in from time to time to see what I've been missing. It seems as though a nice conversation is developing in the altdotnet mailing list regarding BDD Issues. Additionally, a Google Group on Behavior Driven Development has been created which will hopefully provide the same kind of community for BDD as we have for TDD, DDD, and all our other double D topics.

In an attempt to further form my thinking on BDD I'm going to be putting my thoughts down on "paper" (aka this blog) in the coming weeks and months.

This past wednesday I attended the Philly ALT.NET user group meeting and got a chance to see Dave Laribee present on "Planned Agility".  Dave did a great job introducing how to do planning as part of your agile process.  Many people unfamiliar with agile think that planning isn't a part of the agile process, which of course is not the case. 

Planning happens at many levels within an agile process.  The primary types of planning that we do within our agile process are:

• Daily planning: Daily standup meetings start the day and help us figure out what we're going to be working on for the day.  We also evaluate where we are within the iteration and evaluate whether we're on schedule to deliver all the business value that has been agreed to, or whether we need to make small adjustments to meet our goals.
• Iteration planning: At the start of every iteration we have a meeting to discuss what business value the iteration is going to focus on, and then figure out what we can accomplish within the iteration
• Release planning: This is primarily done by our product owner and his team of business analysts.  A lot of discussions occur that help prioritize the features within a given iteration, as well as the scope of those features.  As work progresses within our iterations the release plan is adjusted to add and remove items.
• Product planning: Again primarily done by our product owner, this is the longer term planning that is done to lay our the longer term roadmap for the product, and to schedule the releases that are defined as part of the release planning.

Although it's not a planning activity per se, one of the other key things that often times affects our planning is our retrospectives.  Retrospectives may well be the most important activity within any agile process.  Without retrospectives we tend to fall into a rut, lose track of the problems and inefficiencies within our process, as well look past the ways that we could be improving our team, our software, and our code.  Our retrospectives often lead to planned activities and/or meetings that go into our next iteration planning session.   If you're not doing retrospectives, start.

Planning is an extremely important part of any agile process.  If you're doing agile without planning you're doing something wrong.  I suggest you try and catch Dave's presentation on "Planned Agility" at one of the upcoming conferences he's presenting at.

So, the iPhone SDK is supposed to be announced sometime soon, and as such I realized that I needed an iPhone in order to experiment with it. :)  My new toy should be arriving soon!  My current phone sucks, so I'm looking forward to the goodness that comes with an iPhone.

Recently a co-worker (Aaron) started learning a bit about Lisp. After a little sales pitch, I decided it might be fun to learn Lisp as well, afterall I've heard people talk lovingly about it a few times.

It's interesting to read about a language that has been around since the 50/60's that has many of the language features that we're just now getting in C#. Over the years I've had a lot of people recommend learning a functional language like Lisp, Scheme, or Smalltalk but I've never taken their advice. While I'm not sure I'll ever code anything of substance in Lisp it has been interesting to learn about the language, as well as it's history.

Lately, I've been working my way through Practical Common Lisp, which is published by Apress. In addition to being available via Amazon and other online retailers, the book is available for free online at: http://www.gigamonkeys.com/book/.

I haven't decided on a language for 2008, perhaps because I feel like I have a ways to go still with my language for 2007, Ruby. Anyhow, I'm pretty sure I'm going with something functional, perhaps Lisp...or F#?