Phoenix First Two XP Sprints

Phoenix has finished its Sprint 5 and 6, which are the first two XP Sprints.

An XP team always goes through four stages, "forming, storming, norming, performing". The first Sprint felt like a storming stage, where we are trying to figure out the best way to get the code in without spending too much time on upfront design. At the same time, we are also getting used to paired programming.

Even though paired-programming has become an old trick for me, I still feel that my pairing skill has gotten worse during the past three years of working solo. The second Sprint felt a lot better, and I am hoping to keep this trend.

Items that worth noting:

• We modified the lava lamp to have a green light on when everything is good. Even though it is redundant, it has very positive effect among us. The only thing we might need to watch out is that someone mentioned that they could be fire hazard because the lamp gets very hot at the end of the day. So we are going to turn them off by the end of the day. This is when I found out that the X10 remote controller does not work, so they are back for replacement now.
• The lava lamps are helping us getting on the habit of treating broken tests as the highest priority. Due to the nature of Phoenix, we got some interesting test breakage already. We got tests that only break on the server, tests that only break on Linux, and a test that hung. One interesting discovery is that each time we are forced to figure out what is wrong and fix them, our tests ended up making better sense and being more like behavior driven, and I was planning on settling for hacks to keep the test passing!
• At the beginning of the project, we chose to create just enough stories to get us through the first Sprint, then created a few more for the second Sprint. Looking back, I think that is a good choice. The kind of stories that we create now are so much different but better from the earlier ones. I think that is because at the beginning, your system has literally nothing. It would take a very good story writer to come up with a list stories that really fit into the "INVEST" category of the story. I am not saying it is impossible, I just think that two Sprints of bad stories is not a bad price to pay to get the ball rolling as early as possible and avoid lots of hassle to learn and teach and debate about good stories vs bad stories.
  

Greate Article on Pair-Programming

All I can say is that this article says EXACTLY how I feel.

http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/

One thing to add is James Shore's Programmer Man's Theme Song (see end of the post)

Paired Programming

I posted this internally at Guidewire today in response to a "meta-analysis of empirical studies done on analyzing the effectiveness of Pair Programming." shared by colleague. Then I thought this is actually a pretty good short summary of my point on Paired Programming nowadays:

As useful as they are, my problem with these analysis is that they are trying to isolate the behaviors that work best when applied together. This applies to TDD, team development, short iteration, continuous integration, etc.

Unlike engineering, software development is actually a discovery process, during which most of the value comes when discoveries are put together. For example, when two heads get together, the value is not only about performing complex programming tasks correctly, sometimes it is actually more about realizing that there are other parts in the system that can help with the current task, or even not to attempt because someone has already tried.

On the other hand, programming is a highly concentrated task. Once interrupted, it always takes a while to get back to the mode, and we all know how frequent interruption is during a normal work day. With paired programming, you can actually keep the flow even when one person is interrupted for a short period of time. There are practices that you need to do to make sure that this is really the case. For example, it it turns that the the person is going to help another pair for a long period of time, the right thing to do is to switch the pair, etc.

Also the practices of XP work the best when they are working together. For example, rotating your pair routinely help the effectiveness of the paired programming. If you do TDD during the paired programming, it will help the two people to focus and lower the overhead of communication.

One last thing that I have found out about paired programming is that it helps the team communication. Paired programming forces the two people to talk constantly, which creates the "omni-communication". I know some people find it annoying. But I have sit in such environment on many occasions and once you get used to it, the kind of information you can pick up without any effort is very surprising. Many project managers I talked to also reported that because of the "omni-communication" they pretty much eliminated the "status meeting" and replaced it with "issue resolving meeting".

Test Doubles

This is a nice article that covers the topic very well. Stub, Mock, etc., are all part of the test double.

Pay attention to the very first paragraph. Going out of this context is how mocks are getting abused.

One Week in SLC

The past four days just flew by and I am now sitting at the airport waiting for my flight back. I was hoping to fly my wife over so that we can visit the mountains around here during the weekend but it turned out to be much more expensive. That is OK, I still need to scout out the beach park where I am going to host the BBQ party next weekend.

I held on to a story card and paired with different developer each day. The domain that this story affects turned out to be the worst part of the application so each day I did a bit of clean-up and refactoring. The story dragged on a bit but I managed to make steady progress.

Since this is a .NET project, there are SQL server and IIS server to run on the laptop. After figuring out how to start and stop the service from the command, I wrote two Ruby driver class for them in the hotel room and checked them into BuildMaster.

So now I have a script that I can call to stop both service with:

services.rb stop

and all it does is:

services = [
BuildMaster::IisDriver.new, BuildMaster::SqlServerDriver.new
].each do |service|
service.send ARGV[0]
end