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.

This weekend around 100 folks have descended upon Austin Texas for the ALT.NET conference.  There has been much written about ALT.NET, what it is, how people are misunderstanding it, why it was created, why people should be interested in it, and why it will dominate the world.  Unfortunately, it's all lies.

The truth is, ALT.NET is a scam.  I hate myself for being the one to figure it out, and now for writing this post exposing ALT.NET for what it really is.  The truth is, ALT.NET was created so that a bunch of nobodies [1] could get Scott Gu, Martin Fowler, and the others in the industry whom they have a geek-crush on to come to their conference.  All that talk about making better software, using the best tool for the job, its all bogus.  ALT.NET is all about trying to rub elbows with Martin Fowler. Sad. [2]

[1] by nobodies I mean people whom I love and respect :)
[2] Or maybe its for real and I'm just sad that I didn't go?

On Friday I went to Ruby East and got to hear a bunch of good presentations on Ruby as well as Rails.  In addition to getting the inside scoop from some Ruby experts I also spent some time with Brian talking about the Philly ALT.NET user group.  From what I know about the somewhat controversial ALT.NET movement, I think I fit the general demographic.   If you're a .NET developer in the Philly area, and identify with some of the things that fall under the ALT.NET moniker, I'd strongly suggest you subscribe to the Philly ALT.NET yahoo group.  A first meeting has not been scheduled as of yet, but it's coming shortly. 

Subscribe to the Philly ALT.NET Yahoo Group

James Avery poses an interesting question in his "How long before ALT.NET becomes NOT.NET?" post.  I'm not really sure what it takes to get into the ALT.NET club, but from what I know I'm guessing I'd fit into the general "demographic".  Like James, I've also been wondering if and when more of the ALT.NET'ters will turn to Ruby on Rails (or alternates like Django).  I've thought about this a bit more lately since I've been spending a lot more time in Ruby and Rails.  In addition to wondering about other ALT.NET peeps, I've also thought a bit about where I want to go with my development efforts and whether I want to continue to focus on .NET as my primary means of making a living. At this point I don't see myself doing anything drastic.  Considering I only have 2 Rails projects under my belt and a heck of a lot more to learn about Ruby as well as Rails I think that's a pretty wise course to take.  I am going to continue on my path to learning Ruby as best I can, afterall it is my language for 2007.  I'm also going to continue to do projects with Rails, try and write a lot more Ruby and Rails related code from scratch (plugins make life way too easy), and evaluate if there is anything I've learned from Ruby and Rails that I can bring over into my .NET related work.  I'm also going to be keeping a close eye on IronRuby, and anxiously awaiting the day when they announce they can run Rails on top of it! 

At the end of the day, I believe learning Ruby, Rails, as well as many of the other things I'm looking into, will make me a better developer.  Whether or not I end up building the software I work on in .NET, Ruby, or Erlang doesn't matter much.  I think we all owe it to ourselves, as well as our customers, to question whether what we're using today is the best tool for the job.  We also owe it to ourselves to question whether we'd find more enjoyment in working with other languages and tools.  After all those questions are raised and answered we still need to make a decision based on where we are in life, what we have control over, and where we want to go in the future.

Perhaps before the migration to Rails starts, Microsoft will change its ways and learn a thing or two about what it takes to make ALT.NET developers happy.  Perhaps they'll realize that designers, wizards, and other magic isn't what where it's at.  Perhaps they'll realize that baking best practices into the platform is a good thing.  Perhaps they'll have a look at TextMate and realize it doesn't have any designers, yet Rails developers love it?!?!?  Perhaps they'll learn a thing or two from the success of Rails and stop the floodgates from opening.  What do you think?