A couple nights ago I was up reading blogs and browsing the web.  I had made my way through all my unread items and was contemplating hitting the sack when I decided to do one more "r" within google reader to see if anything new was available.  Surprisingly one new item appeared.  The one new item was from Jean-Paul Boodhoo, and was entitled "The Dream Giver".

After reading JP's post I figured I'd drop him a comment since I like reading, and I like free stuff.  As I went to bed I figured I had a strong chance of being one of the first three to contact him since I'm pretty sure I was reading his post while his mouse button was still pressed on the "post" button.  As I thought about it some more, I realized that I'd actually prefer NOT to win since I would have picked up the book anyway, and I figured there might be some others who responded who wouldn't purchase the book if they didn't win a copy from JP.  Not surprisingly the next day I received a Amazon Gift Certificate from JP to cover the cost of the book.

When I got home that night I mentioned the above to my wife, and told her that I felt bad accepting the gift certificate from JP given the circumstances.  She said I should accept his charity, so that's just what I did.

Over the last two days I made my way through The Dream Giver by Bruce Wilkinson.  The book starts with a parable about an Ordinary guy living in a Familiar place who realizes he has a Big Dream.  As this Ordinary guy thinks about his Big Dream he realizes that he doesn't want to ignore it any longer.  Thus begins his journey.  

As I read The Dream Giver I started to think a lot about my dreams.  As life goes by we often lose sight of our dreams, and get caught up in the comforts of life.  The Dream Giver has me thinking about my dreams again.  I found the story of Ordinary following his dream, as well as the encouraging words and advice offered by the author inspiring.  Life is full of obstacles, roadblocks, naysayers, and will provide you with endless reasons not to follow your dreams.  The Dream Giver offers hope, encouragement, and guidance.  Following a dream isn't easy. You can't do it alone.  However, the journey can make you stronger, happier, and more fulfilled.

Are you ready to begin your journey?

Following in JP's footsteps....the first 3 people to email me with interest in this book will receive an amazon gift certificate in the amount required to purchase the book.

Note: you can email me by clicking on the little envelope in the right hand navigation of my site.

Sorry they are all gone!

We've been using Rhino Mocks as our mocking framework for the last year and have had some good success with it.  Previously, we were writing our mocks by hand, which was a major pain in the ass.  While Rhino Mocks offers a lot of great features and has aided our testing efforts in many ways, it has also caused us some pain.  I've recently been hearing a lot of "buzz" about Moq, a new mocking framework developed by kzu.  This morning I read Daniel's "Why do we need another .NET mocking framework" post and I'm convinced that I need to give Moq a try.  A lot of the points in his article ring true to me, and make me wonder if I would prefer Moq over Rhino Mocks.  The interesting thing with trying a new mocking framework when you're involved in a large project that has already made a considerable investment in another mocking framework (Rhino Mocks) is how you go about trying it, and what you do if you prefer it to what we're currently using.  Ah the joys of software development.

I found the following links on the Moq google code homepage interesting:

• Why you will love Moq (with screenshots!)
• New Moq features for mock verification and creation
• Mocks: by-the-book vs practical
• What's wrong with the Record/Reply/Verify model for mocking frameworks
• State Testing vs Interaction Testing
• Mocks, Stubs and Fakes: it's a continuum

Tonight I was...well....I actually don't remember what I was doing, but somehow I ended up on 22books.com.  For those of you unfamiliar with 22books.com here's a little snippet from the homepage:

22books is dedicated to the creating, sharing, and viewing of book lists. Start out by browsing some of the featured lists to the left and then open a free account and start creating lists of your own.

I created a couple books lists on 22books that contain many of my favorite books on software development.  The lists have a lot of overlap but I broke them up as follows:


All time Favorite Software books

Agile Books

.NET Books

Architecture / Design

Ruby and Rails
I think 22books.com has the potential to become a really great place to share books lists.  I really enjoy reading and have relied on many of the books in the above lists to help me progress as a software developer.  I'll probably spend a little more time refining the above lists and adding books that I didn't think of during my first pass. 

Tonight I was chatting a bit with a co-worker about IronPython and IronRuby and decided to have a look at IronRuby.  Getting started is supposed to be pretty easy.

1. Checkout the IronRuby source from RubyForge

svn co svn://rubyforge.org/var/svn/ironruby

2. Install Ruby via the Ruby 1-click installer: http://rubyforge.org/projects/rubyinstaller/
3. Open a Visual Studio Command Prompt
4. Install the pathname2 gem by running the following from the command line:

gem install pathname2

5. Compile IronRuby by running:

rake compile

Unfortunately when running "rake compile" I get the following errors.

C:\Development\ironruby\trunk>rake compile
(in C:/Development/ironruby/trunk)
Read in 17 resources from "C:\Development\ironruby\trunk\src\microsoft.scripting
\Math\MathResources.resx"
Writing resource file...  Done.
Read in 49 resources from "C:\Development\ironruby\trunk\src\microsoft.scripting
\Resources.resx"
Writing resource file...  Done.
rake aborted!
Command failed with status (0): [csc /nologo /noconfig /nowarn:1591,1701,17...]
C:/Development/ironruby/trunk/rakefile:197:in `exec'
(See full trace by running task with --trace)

I did a little digging around to see if I could find out what was causing the above problem but didn't uncover anything.  In hopes of making some progress and seeing ruby running on top of the CLR, I decided to try and compile using the IronRuby VS.NET solution file. Compiling IronRuby using the VS.NET solution file built everything into the \bin\debug folder.  Once that was done I was able to run rbx.exe and do a little experimentation.  rbx didn't behave like I expected and seemed to be acting pretty flaky but I was able to put in some simple Ruby expressions and see the results I expected.  Now that I have the source downloaded and compiled I'm going to dig into things a bit more to see where things stand. 

Some resources that I came across that might be useful to others include:

• http://ironruby.rubyforge.org/
• http://rubyforge.org/projects/ironruby
• http://www.ruby-forum.com/forum/34
• http://rubyforge.org/pipermail/ironruby-core/

Well it turns out Twitter just turned off allowing anyone from accessing their site via cross domain requests because of a security hole that was found.  It sounds like they're going to be doing some good things to enable access to their api through cross domain requests but it's going to take a little while.  For the time being I'll probably add a proxy to my own site so I can continue to play around with Silverlight.  It is pretty amazing that literally the day that I try and use Twitter's api via Silverlight they turned off outside access.  For those interested they're going to be doing the following within the next month:

1. Move the Twitter API to api.twitter.com.  Use the completely permissive crossdomain.xml on api.twitter.com.

2. Stop supporting HTTP Basic auth. on api.twitter.com.  Implement OAuth or some other kind of auth. token system.

3. Require non-public API requests to include a valid user auth. token.

All three items were recommended by some chap named Dossy on the Twitter Development Google Talk Group.  On a side note OAuth seems to be gaining some traction and definitely needs some more of my attention.

Last week I started having a bunch of problems when visiting some of my favorite sites.  Certain sites would freeze up both Firefox and Safari when I visited.  Since I hadn't had any problems with these sites for as long as I could remember and hadn't updated my browsers lately I was confused about what migh tbe going wrong.  After a couple days of getting annoyed and having to restart my browsers I had a revelation.  I had recently installed Silverlight 2 Beta 1, and all the sites I was visiting had flash on their homepage.  It turns out that something with Silverlight 2 made it so flash broke.  I ended up manually uninstalling Silverlight, restarting, and all was good again.

Tonight I decided that it was time that I checkout the Silverlight 2 beta release.  There are a number of things that I want to try with Silverlight, unfortunately, a bunch of other work has been keeping me.

I decided that the best way to get started would be with a real simple client.  Creating a simple silverlight control for showing recent tweets from Twitter seemed like it would be a fun experiment.  To get started I wanted to download some tweets from Twitter and show them in a ListBox.  Since LINQ to XML can be used with Silverlight 2, I figured the process would be pretty painless.  Of course I forgot about the fact that everyone had to go and try and make everything on the web secure.  From what I can tell, the fact that Twitter doesn't have, or has recently botched, their cross domain policy file is preventing me from being able to make any progress on my little silverlight project. 

Hopefully I'll figure out what the deal is with Twitters cross domain policy file.  It might be that I have something botched since when I run ScottGu's Digg sample I get the same "Download failure" that I get when attempting to download XML from Twitter.

UPDATE: Well it looks like the problem is that Twitter's cross domain policy file only allows *.twitter.com and *.discoveringradiance.com.  That sucks.  I guess accessing the XML directly from Twitter is out of the question.

For all the ranting and raving I do about agile and how it's the best thing since sliced bread, you might think that I am of the belief that in order to create great software you HAVE to be doing agile.  After re-reading my post yesterday about the sloppiness of Agile, I realized that the post, and likely many others I've written, could lead people to think that I believe the only way to create great software is by pair programming, having weekly iterations, having retrospectives, and doing everything else that the agile guide book tells you.

Not so.  While I do believe that the agile principles and practices that many of us follow greatly increase our chances of success, they are by no means a silver bullet, and they are by no means a prerequisite for great software.  If you're doing waterfall, RUP, scrummerfall, or whatever else and creating software that your customers love, then keep rockin the process you're using.

My experiences give me a bias towards agile, and the many practices that it recommends.  I've seen it work well in ways I don't think waterfall would have.  I also really believe in many of the core coding practices that agile recommends.  Most especially: test driven development (TDD), continuous design, refactoring, YAGNI, and keeping it simple.

I think agile gives me a better chance at creating great software and that's why I use it.

warning: this post contains higher then normal sarcasm levels

Over the last couple weeks and months I've had a number of people share what seems to be a common Agile misconception.  I've never heard anyone say this first hand but my impression is that it goes something like this.

Agile lets programmers do whatever they want, they never have to ship, they don't have to follow anyone's rules, and they can be as sloppy as they want.  Cowboy coders of the world unite....oh and sign this here agile manifesto while you're at it! 

Having worked in an agile shop for the last 3 years, as well as advocating and making small inroads at my previous employer for a couple years prior, I feel like I'm reasonably qualified to speak to whether that statement is true or not.

To be honest with you....it's completely true!  I am proud to say that over the last 3 years we've created some of the crappiest code known to mankind.  We haven't shipped anything to anyone since we get to decide when the software is done, and well, we've had much better things to be doing.  We make all our own rules, which we've found best to make up on the fly.  It's really a great setup.

There is just one thing.  For one, we do this thing called pair programming.  If you haven't tried it, it's where two programmers sit at a single computer and write code together.  We do it close to 85% of the day, and the vast majority of our production code has been written in this fashion.

There is something strange about pair programming.  You see when you program alone it's very easy to be tempted.  Tempted by the internet, by your email, by your shinny new iPhone.  It can also be tempting to take shortcuts in your code, do things the "easy" way instead of the "simple" way.  As long as it works and nobody else has to look at the code again, who could it hurt if it's mostly unreadable?  As long as that bar goes green we're good, right?  Actually, if we get rid of the green bar, we don't have to worry about wasting our time making it turn back green when it suddenly decides it wants to be red.

Pair programming doesn't allow you to be sloppy.  Actually that's a lie, it does, but it makes it twice as hard.  Not only do you have to be a slack ass, but your pair also has to be a slack ass.  And you and your pair both need to not care about the fact that you both know you're being slack asses.  And you and your pair need to also not care that when the next pair comes along and picks up  your code they're going to know you're slack asses.  Maybe that makes it more then twice as hard?  The point is, pair programming is really good at reducing the amount of slop that you let into your code.  So come to think of it, maybe that being slopping part isn't really true about agile.  But, at least we still don't have to ever ship anything.

Hrm, but we do have those weekly iterations (that's another lie our iterations aren't weekly at the moment).  The thing about weekly or biweekly iterations is that they force you to be able to "ship" something at the end of every iteration.  I say "ship" with quotes around it because we all know that you're not really able to physically ship every iterations set of work to a client.  There is a boat load of stuff that needs to be done in order to actually ship.  You need to make a branch/tag in your source control provider.  You need to package up the software, burn it to a CD/DVD, prepare release notes, and a bunch of other stuff.  But you could ship something to somebody, even if at the very least it's to the QA department.  On non agile, or more correctly, non iterative projects that doesn't happen.  Come to think of it this iteration thing seems to put a lot of restrictions on the development team.  Let's outline a few of the things that are popping into my head:

- Forces development team to continually stay focused on meeting delivery dates, as in every week or two
- Forces development to communicate with one another constantly about the status of the iteration
- Puts a pretty rigid schedule in place for the development team
- Focuses the entire team on the work at hand, and what needs to be done to get it done by the end date
- Allows the product team to have visibility into what the development team is working on every day and what progress is being made

I'm not sure if everyone's agile process is like ours but it's probably the furthest thing from "cowboy coding", "sloppy", and it most certainly doesn't allow the development team do whatever the heck they want.  On the many non agile projects that I've been on in my career I had a lot more flexibility with how I spent my day.  As long as when that date hit down the line everything was done, I was good.  In many regards I had free reign to do whatever I wanted, I could code the thing however I wanted, and could have made a complete mess if I wanted. 

Working in an agile environment is much more rigorous and disciplined.  We have a very strict set of principles and practices that we follow.  We pair program, which means we have two people working on most production code, which leads to much less slop code, much less just get it done code, much less we're never going to look at this again code, much less who cares what it looks like the test passes code.  Our agile process defines a very rigid schedule for us that defines when, and in many cases how, we do everything we do.  

If anyone ever tells you that Agile is easy, that it's sloppy, that it lets the development team do whatever they want, they haven't been on an agile team doing it day in and day out.  It's hard.  It takes discipline.  It's draining.  It can be monotonous, invigorating, scary, frustrating, annoying, enjoyable, puzzling.  If you're doing it and it's "sloppy" you're not doing it.

In my post summarizing some of my thoughts from the latest Philly ALT.NET meeting on Planned Agility I alluded to the fact that the retrospective is a key component within our agile process.  Since it sounds like we have a slightly different flavor of retrospective then some others I thought I'd put together a post detailing how we run our retrospectives.

A couple times over the last few years our team had the pleasure of working with Jim Shore, author of a great agile book entitled The Art of Agile Development.  Jim introduced us to the style of retrospective that we're using "today".  While we've strayed away from the format I'm about to outlay a couple times, we've found that it provides us with a good foundation within which we can get to the root of the things that we want our retrospectives to uncover.

We typically start our retrospectives off by reminding people of the Prime Directive (should we?).  Once that bit of housekeeping is out of the way we try to get everyone involved by going around to everyone that is participating in the retrospective and have them answer a question.  The primary purpose is to get people engaged, and speaking as early as possible.  The moderator chooses the question, and a "fan favorite" seems to be "What do you hope to get out of this retrospective".

Next, we review our team objectives.  As I'll get to in a bit, we try and end each retrospective with a team objective.  By starting off each retrospective with a review of our objectives we ensure that we maintain focused on the objectives that we've defined.  During this time we evaluate how we're doing with each objective, whether or not they need to be altered, dropped, or given a kick start.  

After reviewing our objectives, we go into an information gathering session.  The purpose of this phase is to gather information from everyone in the team, and hopefully identify an item, or set of items that should be further addressed.  We use index cards for everything under the sun so it shouldn't be surprising that we use them for this process as well.  The way this stage works is that everyone on the team is given a handful of index cards and a pencil.  Each person reflects upon the last iteration (or whatever period of time it's been since our last retrospective), and identifies things that fit into one of the following topics:

• More
• Same
• Less
• Enjoyable
• Frustrating
• Puzzling

We usually take 5-10 minutes to allow everyone to write whatever pops into their head on their index cards at this point.  When I'm leading the retrospective I often encourage people to prepare ahead of time for this phase.  Once everyone has had enough time to write their cards, we go around and everyone reads the topic that their card goes within, and then gives a short overview of what is on their card.  Once everyone has had a chance to go we allow people to put up cards that they've thought of as everyone else was going around.  Once everyone is satisfied that they've gotten their major items identified on the board we begin the next phase.

Once all the data is collected on the board, we have everyone organize the cards into categories.  The categories are pretty loose and can be whatever anyone sees as fitting.  There is usually some debate at this stage as people discuss whether or not things really belong in category X instead of category Y.  Once this stage is complete, we review the categories that have been identified.  Often there is some slight re-organization at this point.  Once everyone is happy with our categorizations we do a quick vote to see what category people feel is the most important.  We then tally the votes and identify the item that is going to be the focal point for our next phase.

With our primary category (or sometimes item) in hand, we begin the discussion portion of our retrospective.  This can take the form of a fishbowl, roundtable discussion, or 5 why's.  The goal at this stage is to drill down into something within our team, process, work habits, communication, or whatever else that needs particular attention.  As part of this discussion a theme usually starts to emerge.  Once it does we identify it, and bring it to everyone's attention.  The primary theme typically turns into a new team objective.

As we go through our retrospectives we try to stay focused on things that we can do to help improve our team, and/or our software.  Since the human side of software is the most important and most problematic, you won't be surprised to hear that our objective usually has something to do with improving the dynamic between some members of our team.  We write our objectives on a wall in the development area for all to see with the idea being that if it's in everyone's face all the time we'll be more likely to meet our objectives.

I breezed through a lot of the details of our retrospectives above in order to get a reasonable summary up and out into the wild.  If you have questions about anything mentioned above or would like me to further expand upon anything mentioned drop me a comment.  If you haven't had a retrospective in a while, now is a great time to schedule one! :)