I invited Liz after meeting her at the BDD workshop I ran last week. We were very lucky that she was free and available at short notice. I felt we had a pretty good agile system set up here, but we’d not scaled it to a larger team (6+) before and we were coming up against issues (such as the best ways of estimating) which we felt Liz could help us with.

It’s been enormously beneficial to have Liz with us. Much of our practice were validated: pair programming, co-location, BDD, outside-in, continuous integration. These are core tenets of our process which have been proven in many companies. Instead of changing our basic practice, Liz has helped us to the next level through much conversation and discussion.

Here’s a few snippets of what we’ve learned and how we’re tweaking our process to give our clients the maximum number of features with the shortest possible lead time.

Use Feature Injection to force the value question

One small change with big ramifications is the concept of Feature Injection.

In brief, this means changing the way you write stories so that instead of having:

As a 
I want 
so that 

You have:

In order to 

will need
.

Rather than just a way of specifying technical stories, we realised that by putting stakeholder value first, we are forcing the question of what’s actually necessary about this feature that causes us to do it in the first place. This ties our stories very much to stakeholder value, which ensures that everyone knows exactly what value is being provided when they’re working on a story.

Read more about Feature Injection here.

Keep completed stories visible

Once our stories are clearly about stakeholder value, it’s important for everyone to see exactly which features currently exist, preferably broken down by stakeholder. We’re working on ways of getting the features list that we’ve already completed more visible to our clients. Once everyone can see what’s been delivered so far, it’s much clearer what should be worked on next.

One way of doing this might be a small Rack app which handles /admin/features and returns all the features grouped by tag… does anyone know of a Rails plugin that might do something similar?

Ensure you can always release

If we’re truly doing BDD, then we are delivering tiny slices of functionality that can be released immediately. Often we batch these into releases, often accompanied by a rather laborious and crunch-like polish process.

However, there’s no reason that we shouldn’t be ensuring that the site is release ready at any point. If this is the case, the stakeholders have the option to say “Done – ship it!” whenever they like, and we’re able to do this straight away, rather than after a three week polish + skin period, and the dreaded IE6 compatibility check.

Lesson learned: Get a site release-able as fast as possible, and keep it there.

Put performance tests in the build

As developers we are always concerned about timing our performance improvements. How do we balance over-optimising a site with doing performance testing too late and risking a meltdown? How do we ensure that performance is kept at an acceptable level?

If the goal is to always keep a project release ready, then we need to ensure that our new system hasn’t introduced any serious performance issues, which bring it below a minimum performance level. If you are guaranteeing to your client that your site can handle a certain level of traffic, then anything that breaks that effectively breaks the build. Therefore, what better way to do this than make your performance tests part of your build?

And there’s more…

I plan to blog further about some of the other things we learned: including the major insight about the benefits of a Lean approach, which is worthy of its own post.

Do you have strong opinions about the above? Do you disagree? Let us know!

I really enjoyed doing my first talk about Ruby/Rails – teaching it was great fun. Even though I’m sure we can improve further, we get a lot of value from BDD, Cucumber and RSpec and it was good to pass that on and give something back to this excellent community.

The workshop was free – if you got something out of it please make a donation to the Red Cross through the Rails Underground donation page.

Update: the video is now available here. If you were there, there’s a rating and feedback page for it.

All this... for nothing?

I’ve been digging around for a decent agile PM tool for a while, and stumbled across Pivotal Tracker on Twitter a couple of days ago.

Within about thirty minutes of trying it out, I was totally hooked. We’ve rolled our own basic project management tool internally, but we’ve yet to get the time to put proper iterative development support into the app. Pivotal Tracker just works. With a clean UI and some great reporting tools, it’s all I need to run an agile project.

The one big downside is this: it’s completely free.

Wait, you say: surely that’s a good thing? Well, yes and no.

Why great software should cost money

When I pay for an app on the net, I expect a few things:

• It’s going to be up pretty much all the time.
• It’s not going to vanish tomorrow.
• It’s not going to suddenly cost a fortune.

With Pivotal Tracker, I’ve no idea when they’re going to take the software down for maintenance. I’ve seen reports of it going down without notices for 15 minutes here and there, which is fine if it’s a non-critical service. It is however most definitely not fine when my client is trying to comment on features. I also have no guarantee that it’s not going to suddenly disappear into the night, taking all my stories and possibly the project itself with it.

The other issue is that if I’m paying $20/month for it, I’ve a reasonable expectation that it’s not going to cost say $200/month next month. It’s well within Pivotal’s rights to withdraw the free service and charge what they like for the paying version, without any notice.

Are we going to use it anyway? Yes we are: it’s too good to ignore. However, we’ve put in place the following cron job to mitigate the risk:

*/20 * * * * curl -H "X-TrackerToken: " -H
 "Content-type: application/xml" -X GET
 https://www.pivotaltracker.com/services/v2/projects/39382/stories
 > stories-backup.xml

This little piece of magic copies all our stories in XML form to our backup server every 20 minutes, so we’re not screwed if the site vanishes without notice. It would only take us about an hour to import this XML into our old system should we need to. That takes care of the main risk for me.

The conclusions: Some software shouldn’t be free. If you’re using Pivotal Tracker or any other free service in anger, make sure you’ve got a backup plan.

The best way to get what you want is to do it yourself, right? Therefore I’ve created a meetup group for it. The main aim is to discuss such things as: best practices in running a rails consultancy (of any size), best-practice ruby on rails development/project management, this Rails Maturity Model idea that’s been doing the rounds in the last few weeks, plus anything else that’s relevant.

Anyone who’s interested in the same sorts of issues discussed in this group is welcome to attend. For more details of our first meeting on 4th March, see here.

From the first hour I realised that that these guys (and girl!) were good… really good. Not just that, they were talking in a completely different language to that which I was accustomed. Agile Development? Behaviour Driven Design? RSpec? Outside-in? Fixing broken windows… isn’t this a computer company? To say I was confused and a little scared at this point, would be an understatement. I still had a very big mountain to climb, in fact, my journey had only just started.

However over the last few months that I have been here, I have really started to grasp a lot of these concepts. Not perfect, or master them (that takes time and practice) but the value of them and how applicable they are to modern software design has blown me away. The concept of Agile Development and BDD isn’t completely strange and abstract, in fact, it’s quite simple:

1. Write a story to explain the feature you are adding. (This can be done by the developer or customer)
2. Run the story (it involves Cucumbers, i’ll explain some other time)
3. The story fails (no code yet)
4. Write a spec for the code that you will finally implement (This is the second layer of testing)
5. Write code

The first 4 steps can be repeated a few times before any real code is actually written. When you do come to write code though, you know it works. How? The specs tell you so. It’s magic. Compare this to how I was taught software development in University:

1. Write a design document (This explains the entire system and its individual components)
2. Create UML diagrams and User Specifications for every Class in the system and how they interact
3. Write code

Fewer steps, it must be quicker. What I didn’t mention was that the first two steps can take months alone. Often by the time that you actually come to write some code, a feature of the applications design has now changed, this means that has to be re-written and the diagrams all updated. Further delays. This monolithic approach is largely inefficient and frustrating!

So Agile Development works out better for the customer and better for us programmers (we actually get to do what we love doing!). Coupling that with strict testing at every step ensures fewer bugs and greater flexibility. You can approach each new feature/problem with confidence knowing that if any change you make breaks another part of the system, it will be caught by the tests failing. This is why the staff at Eden actually love doing what they do. They get to write awesome software, and have fun doing so. Compare this with the Games industry which is full of programmers who are overworked and burnt out. They were in what they thought was their dream job, but really wasn’t. I still have a mountain to climb to reach my new goals, but I’m having a lot of fun doing so!

Eden is a great company, with extremely talented staff. We have lots of really interesting projects spanning many different industries. I think this mountain will be quite fun to climb :)

One of the most useful aspects of RSpec and BDD is how it can highlight areas of your code that are obvious targets for improvement.

When we write our specs before our code we are effectively writing the API, the contract that our code must fulfill. It’s often the case that if this contract is hard to write, or just looks clumsy, then there may be a better way to express it.  This makes RSpec our first way of detecting code smells.

Perhaps the easiest type of code smell to detect with RSpec is Law of Demeter violations. Imagine a simple Ruby on Rails task management application. Tasks can be owned by Users. There may be many places where we would want to show who owns what Task. The simplest way to do this in Rails would be to use a belongs_to association to expose the attributes of the User to the Task. This makes it trivial to get the name of the user who is assigned to a task:

class Task < ActiveRecord::Base
  belongs_to :owner, :class_name => "User"
end

# to get the owner name:
task.owner.name

While this is easy to write, it would make our specs more complex. Anywhere we wished to mock the name of the owner we would have to write something like the following:

task.stub!(:owner).and_return(mock_model(User, :name => "Bob Smith"))

There’s a lot of noise in this line. We’re creating a mock object just to produce the name of the user. Typing and maintaining test code like the above just seems unnecessary — we’re mocking more than we need. Perhaps worse, it doesn’t express our intentions clearly. We’re asking the task to return its owner, then asking that owner to give us its name. Instead of this approach, we can define the contract as we go and we can actually express our intention:

task.stub!(:owner_name).and_return("Bob Smith")

This makes our tests look tidier, but it actually has a more beneficial side effect. Even though we now have to write more code (speccing then adding the owner_name method to the Task class), it’s now the Task’s job to find the name of its owner. This makes our code more maintainable. For instance, imagine that not every task has an owner. With our original code, anywhere we explicitly used the owner association we would have to change the code to:

(task.owner.nil? ? "No Owner" : task.owner.name)

If this was used many times throughout our code base, we’ve suddenly got a large number of places to find and test this code. By defining the owner_name method early we avoided this problem because there’s only one place that now has to deal with the messy business of finding the name of the owner. Our other specs and stories aren’t broken because they can still happily call the owner_name method without worrying about how this is actually handled.

By using RSpec to help us separate out what information we want from how we get this information, we’ve made our codebase just a little bit cleaner and more maintainable.

This is how i did it originally:

  def contact_display_name
    returning String.new do |output|
      output << title + ' ' unless title.blank?
      if initials
        output << initials + ' ' unless initials.blank?
      else
        output << first_name + ' ' unless first_name.blank?
      end
      output << surname + ' ' unless surname.blank?
      output << suffix unless suffix.blank?
      output.strip!
    end
  end

Rather too long-winded for my liking. I managed to refactor it down to this:

def contact_display_name
    [title, (initials? ? initials : first_name),
      surname, suffix].delete_if(&:blank?).join(' ')
  end

Of course, it is another advantage of behaviour-driven development, that i had already specced out what i wanted to happen, and i could use the specs to ensure that my two versions of the function were equivalent. See below for the specs that verify the behaviour.

 describe "contact_display_name" do
    it "should output the first_name and surname" do
      contact = Contact.new(:first_name => 'Gabriel', :surname =< 'Gray')
      contact.contact_display_name.should == 'Gabriel Gray'
    end

    it "should use the title if there is one" do
      contact = Contact.new(:title => 'Mr', :first_name => 'Gabriel',
        :surname => 'Gray')
      contact.contact_display_name.should == 'Mr Gabriel Gray'
    end

    it "should use the initials rather than the first_name if it has them" do
      contact = Contact.new(:title => 'Mr', :initials => 'G',
        :first_name => 'Gabriel', :surname => 'Gray')
      contact.contact_display_name.should == 'Mr G Gray'
    end

    it "should add on the suffix if there is one" do
      contact = Contact.new(:first_name => 'Gabriel', :surname => 'Gray',
        :suffix => 'BSc Hons')
      contact.contact_display_name.should == 'Gabriel Gray BSc Hons'
    end

    it "should not mind if there is no first name or initials" do
      contact = Contact.new(:title => 'Mr', :surname => 'Gray')
      contact.contact_display_name.should == 'Mr Gray'
    end

    it "should ignore any nil values" do
      contact = Contact.new(:title => '', :first_name => nil,
        :surname => 'Gray')
      contact.contact_display_name.should == 'Gray'
    end
  end

We’ve now switched all our active projects over. I highly recommend you do the same if you haven’t already – it’s a real step closer for us to the ideal situation where customers can collaborate on the text their own stories. Aslak and the rest of the team have a lot to be proud of.

Here are some reasons why i have been won over by the test-first philosophy:

1. One thing at a time
Of course we all like to write very small concise functions, don’t we? But even in a small function, there are usually a few different paths that could be taken through it. It is so beneficial for me to think of scenarios one by one, write up the expected outcome, and then write the function a little bit at a time until it passes all the tests.

2. Confidence
Let’s be honest – who wants to go back and manually test all the things that you’ve tested a hundred times before and you’re pretty sure they’re still going to work? I used to be a tester – that was my job – and I couldn’t stand the monotony. But you can never have complete confidence in your whole system unless you have tested all of it. If you have broken something, it’s much better to know sooner rather than later. When you have a complete set of tests to run after every test you can be completely confident in your application.

3. Prove the obvious
Sometimes I’m writing a piece of functionality and I think, “Oh that’s so obvious – I don’t need to write a test for that!” But then I think to myself, if it’s so obvious then I had better make sure that it stays that way. In any case, it may not be obvious to the next person who works on this bit of code. It may not even be obvious to me in a few months time. So I write a test to prove the obvious. If somebody changes it and breaks the test, then they will be forced to think twice about the change they are making.

4. A greater understanding
Step-by-step stories are a wonderful way of understanding a system. Often when I’m coming to a piece of code I’ve not worked on before the first thing I do is work through the story. It may be enough just to read it through to see what happens when, and why. Sometimes I literally follow every step of the story, performing it manually to see for myself what it does. Once I understand what is supposed to happen, I’ll have a far better chance of following the source code. So be kind and write nice stories for the next person who comes along and wants to understand your code.

We write our behaviour-driven-development stories and specs using RSpec, and we are currently converting to Cucumber to run our test suites.