For the last week, I’ve been embedded with a group of contractors at work who have been developing some new internal tools using Ruby on Rails. I intend to blog a bit about what my experiences have been as time goes by so that I can capture the ideas that I’ve been picking up from my time on the team.

The team practices Extreme Programming which is the software development methodology which I’ve been interested in for the last six or seven years. It was the reason that I sought out the job with Symantec a few years ago and nothing that I’ve done in the time since has compared in regard to my productivity and my enjoyment at work.

First of all, the quality of the team is immediately evident. They are a group of very committed and focussed individuals. They spend more time than most teams ensuring that the object models and code are as clean, simple, and organized as possible. When they find a way of improving some aspect of their work, they take the time to build a tool to make that task simpler, then make sure everyone on the team has access to the tool. For instance, in the past week, one of the development pairs (XP involves pair programming) began working on an Ubuntu Linux dev box instead of the standard Mac Mini stations. They had identified the JEdit editor as a suitable candidate to replace TextMate on the Linux platform. TextMate provides several features that JEdit doesn’t have out of the box and they (or other members of their organization) have developed several Bundles for TextMate that improve their efficiency in coding. The leader of the Linux effort took the time to identify identical plugins for JEdit and wrote one or more plugins to provide identical (or similar) functionality for the most used TextMate features. Too often, I’ve seen programmers either suffering silently with inadequate tools, or building small tools for themselves without sharing them with others. One other thing about editors - this team really knows its editing tools - I’m constantly asking what the key combo was that my partner used to do some cool operation in the text that otherwise I might have done manually. This was a thought from The Pragmatic Programmer that these guys have really taken to heart.

They are obsessed by testing. They test every conceivable aspect of the code (always with automated tests) and use Test Driven Design (TDD) exclusively. This provides many code quality benefits, but most developers don’t have the self-discipline to accomplish this. The pair programming that they practice is also helpful in this regard (more on this below). They go beyond the standard Ruby on Rails ways of doing automated testing in the following ways. They use the UnitRecord, Mocha, and Dust testing extension libraries.

UnitRecord is a tool which permits removing database access from your ActiveRecord based classes. This greatly reduces the time it takes for each test to run - which is a good thing when you have the number of tests that this team produces.

Dust is a tool which permits you to write test cases like this:

functional_tests do
  test "given no name, when validated, then error is in the objects error collection" do
    instance = Klass.new
    instance.valid?
    assert_equal "can't be empty", instance.errors.on(:name)
  end
end

instead of deriving a class from Test::Unit::TestCase and adding methods that start with test_

Mocha is my favorite of the new tools. It is a library which provides the ability to mock and stub out classes and methods in a manner similar to jMock (which it is inspired by), but it provides a cool feature that I don’t believe that jMock does: it “…allows you to mock and stub methods on real (non-mock) classes and instances. “ This is a big time saver and lets you isolation test classes without having to refactor the code to avoid dependencies.

For pair programming, the team pairs share a common mac mini which has two monitors, keyboards, and mice (the monitors are mirrored so each developer looks at his own screen and sees the same as his partner). To share time at the keyboard, they play a game which they refer to as ping-pong. The first developer writes a test which the second must write code to satisfy. The second developer then writes a test for the first developer to write code. In this manner, each developer gets practice writing code and tests.

The team has an obsession about simplicity. I value the simplest solutions, but often I have caught myself planning code for the future when I learn that my partner has a simpler way which involves less complexity. For example: don’t add a database table unless necessary - write a hard-coded class instead.

This insistence on simplicity extends to maintenance as well. When the stories for the iteration have been written, one of the pairs was tasked with cleaning up a class in one of our applications which had become a little cluttered over time. The team briefly discussed potential candidates for cleanup and once agreement was reached, the pair started on the refactoring activity.

It has been a good week at work and I’m looking forward to other ideas that I can steal from them in the future - like GotAPI a handy website reference of most common web programming and languages.