agile

Corey Haines stopped by and paired with me on Monday, 12/13/2008, this week. We had a great time talking and hanging out, as well as working on the Red Sun Ruby Flash VM for several hours. We implemented the core trappings for exception handling which was a major missing feature in the VM. We had a long talk about software craftsmanship and the journey that we take in our line of work.

I think the most important lesson that we felt was that a range of experience and interest is beneficial for a craftsman. We both traced some of our best learning and growing experiences back to interacting with key individuals. I also saw again how my path as a developer has been rather erratic as I've worked in significantly different environments with very different goals and deliverables. Overall, I think this has benefited me as a developer as I've been exposed to people with very different mindsets over the years.

Corey posted the video interview on his pair programming tour site earlier today. It was very interesting pairing with someone when the majority of the work was of the kind that was new to the pair. I haven't done a lot of pairing in my career (unfortunately). It's probably obvious to you if you've paired much, but even though Corey probably doesn't know ActionScript 3 well, and has not used C significantly, he was able to point out errors that I would have missed until either compile or execution. It also helped me to explain what I was doing as I went along. It forced me to have a reason for the things that I did.

The downside of this project in particular is that it doesn't lend itself well to Test Driven Development. I know some may argue that everything can be TDDed, but this is a unique kind of project. I am essentially re-implementing Ruby 1.9 (MRI/YARV) in ActionScript 3. This means that I copy, line-for-line, the C code into ActionScript, translating the idioms as I go. This means, as I explained/rationalized to Corey, that I can write large chunks of code without tests - even code that isn't yet running. The benefit of doing this is that when another part of the system gets implemented, those earlier parts will just work, assuming I did it right. Also, the goal for testing is to ruby RubySpec against Red Sun, and at that point I will have lots of failing tests to fix!

When I started working on Red Sun I didn't do this. I only implemented the functions and parts of functions that seemed essential at the moment. This led to significant slowdown and confusion later in the project. My partially complete method was now passed different arguments and data such that it exercised the alternate, unimplemented code path. I found it better to implement as much as possible of each function whenever I encountered the function, and to stub broken paths with verbose error messages or exceptions to point them out should they later execute.

I was very happy that Corey came and I am planning on posting some more insights from our discussions over the next few weeks. I was very happy that we got exceptions implemented. I intentionally skipped all of the exception handling code before RubyConf 2008 because I was afraid of getting stuck in it and having a broken implementation. I haven't implemented all of the various control flow interrupting operations (such as redo, break, and next), but raise and rescue are working pretty well. If you're interested in Red Sun, you can view the video of Red Sun Introduction by Confreaks from RubyConf 2008.

Thanks again for coming Corey! I hope there can be more people who take this journey and they can stop by Muncie if they do.