Agile 2009 summary

I guess it's better late than never, but here's some of the highlights from Agile 2009.

Clean Code Craftsmanship by "Uncle Bob" Martin

This was an excellent talk about software craftsmanship; some of the points that I particularly enjoyed:

• Plans are useless, but planning is indispensable.
• In software, cost of change is low, so the later you think about them, the better.
• No grand redesigns.
• The only way to go fast... is to go well. Basically, you have to put in quality, which contrary to popular opinion, does not slow you down but in fact allows you to go faster. Code doesn't rot; we make it that way and it's our responsibility to keep the code clean.
• Green band: Uncle Bob wears a green wristband to remind him to always keep the code clean, and you can get one here.
• TDD: By following the three laws of TDD, you can always have clean, simple, testable code.
• Most attendees had short iterations of either one week or 2 weeks. Uncle Bob said that perhaps when he asks again next time, iterations may be even shorter!

Debugging Pair Programming by Matt Wynne

Although I couldn't stay for the entire session, since I had to leave to prepare for another day of Programming with the Stars, I thought the session started out okay by identifying the benefits of pair programming.

• High truck number: I've never heard of this phrase before this session. Basically it means that when you pair, you are spreading the knowledge so that it's not just one person who's the expert as in most traditional projects. So if that expert were to get hit (god forbid) by a truck, the team would still be okay. So you can have more people hit by trucks, and the team can still function.
• Free training
• Instant code reviews
• Team building: cheaper than going out for paintball, and less painful.

Each table had a large sheet of paper, some sticky notes, markers, and a persona. This persona was basically someone that may or may not have heard of pair programming, and listed their reasons for not adopting it. Our goal was to list the reasons why they may be afraid to adopt pair programming.

My first table was fine since everyone took a sticky and shared their thoughts. Then we were asked to keep one person at the table, and everyone else move to another table. The person remaining was to explain what we talked about and then discuss how to overcome those barriers.

So, at the second table, I think because there were no moderators, each discussion ended up turning into arguments. Also, some participants' views were not being recorded since the sticky notes weren't being used and it seemed like the guy at the table was filtering out comments. It may have been unintentional but it would have been good to get everyone's input.

Integration Tests are a Scam by J.B. Rainsberger

Originally, I had recorded the audio on my iPhone, and I was going to listen to the whole thing and write down the key points but I think it's unnecessary now since I'd be repeating what everyone else has already written.

To sum it up in a few sentences: basically with integration tests, you end up with a lot of duplication. The tests become slow and brittle, and as we all know, slow tests end up not being run. We want to make sure that in our unit tests that communicate with collaborators, that we are:

1. mocking out the collaborators
2. making sure we are sending messages (parameters) that they can actually handle
3. ensuring that they respond the way we think they do

This is done with collaboration and contract tests.

This is not to say acceptance tests are useless, because they test the entire system from end-to-end. It's that with the right collaboration and contract tests, you do not need to write any integration tests, and therefore, keep your tests DRY.

Programming with the Stars 2009

I was lucky enough to be selected as a participant in Programming with the Stars 2009, and the star I was paired with was James Grenning, the creator of planning poker and an expert at TDD in C and C++, especially in embedded software.

First day

The first day, we were tasked with refactoring existing code. I hadn't programmed in C and C++ in over 5 years, so I had a lot of catching up to do. Thanks to James, I was able to get up to speed in running unit tests, refactoring, etc in Eclipse. We were given only 3 minutes to perform. When you're up there pair programming in front of a live audience, the time really flies!

Day 2

We made it to day 2, where our task was TDD from scratch. It was another exciting day, but both James and I performed on an empty stomach since the competition was far away from lunch. We were given 5 minutes this time.

Day 3

Somehow, we survived day 2 and made it to day 3, where our task was a 6-minute SDD performance. We used FitNesse and CSlim to show the development of a home automation user story. I was amazed at how FitNesse could integrate with so many languages.

It was a close call this day, as we were in the bottom two pairs, but thanks to the audience, we were saved.

Final Day

The final day's assignment was a 6-minute freestyle performance. There was a coin toss to see which team would go second since throughout the competition, it seemed like going first was a disadvantage.

So it would be the team of Gerard Meszaros and Ola Ellnestam, or Grenning/Chien. The non-star partners were called up to call heads or tails. Ola called tails, but during the coin toss, it hit the podium and I called "interference." :)

James and I decided to recap what we did throughout the whole week. Some of the judges liked the idea; others didn't. It was okay; we were only down by 2 points. After the scoring,the audience was asked to vote by writing down their score, from 1 to 10 for each of the pairs. While that was going on, the bonus round was announced: write "Hello Programming with the Stars" to the console using any language, but with the following conditions:

1. Leave the computer in its current state
2. Disable the mouse
3. The star can only type with his left hand, typing only the keys that the left hand normally types. The other partner has to type with his right hand, typing only the letters/keys that the right hand normally types.

While Meszaros/Ellnestam were performing, the audience's votes, averaged and multiplied by three gave Meszaros/Ellnestam an additional lead of three more points.

James and I were thinking of what language to use and decided on C. I had already typed it up and executed it on my personal laptop, using vi and the terminal.

However, when we went up there, I was confused since we wrote it in Eclipse. Although we finally figured out how to run the program, we were a little too late. The other team finished in 1:28; we finished in 2:49.

Although we ended up with second place, I thought the entire competition was a lot of fun. It was great working with James Grenning, and meeting the other stars and competitors, as well the hosts and judges. I learned a lot, and it was an experience that I'll never forget.

Overall summary of Agile 2009

This was my first time attending an Agile conference, and I really enjoyed it. I made a lot of friends, learned a lot of new things, and I'd definitely recommend going to this conference if you've never gone. Hope to see you next year at Agile 2010!