Rails Camp 9

June 24th, 2011

Phew! I’ve just about recovered from Rails Camp 9, an event that may be described as an unconference. It took place over the June long weekend at Lake Ainsworth near Byron Bay on the NSW far north coast.

For this camp, it was my honour to be one of the organisers. Fortunately, Rails Camp now has a well-established pattern and there were many organisers of previous camps willing to help and advise. And I had a terrific team amongst whom to share the workload.

Nevertheless, for the benefit of future Rails Camp organisers, I thought I’d share a few recollections of how our team went about organising Rails Camp 9.

The Organising Crew

I present the wonderful bunch of Rails hackers who all played their part in ensuring that Rails Camp 9 was, to use an over-used adjective du jour, awesome: Jason Crane, Scott Harvey, Zubin Henner, Ben Hoskings, Tim McEwan, Elle Meredith, Keith Pitty and Jason Stirk. (Trivia note: half of this crew were at the inaugural Rails Camp at Somersby in 2007.)

The Venue: Lake Ainsworth

How did we choose the venue? Once we had settled on the idea of holding Rails Camp in the Byron Bay area, the locals in the organising crew – Zubin Henner, Elle Meredith and Jason Stirk – scoured the region looking for a suitable venue and came up with only one that could accommodate the numbers we were expecting.

In many respects Lake Ainsworth was a perfect venue. Nestled between the lake and the beach it had excellent facilities for our needs. The staff were very helpful and I can really only think of two negatives: we were obliged to deal with some unexpected government bureaucracy and we had to hold the camp on a long weekend.

How we organised Rails Camp 9

Settling on the venue was half the battle. Happily, as this photo shows, we were also able to organise the essential ingredients of Rails Camp.

Rails Camp 9 Ingredients

Thanks go to Zubin for organising the beer and Elle for organising the coffee machine. As for the coffee itself, Jason Crane ensured we had excellent beans and well trained baristas!

Speaking of essential ingredients, securing the services of Ben Hoskings to again set up the server and wifi was wonderful. Apart from one brief power outage during the weekend, everything ran as smooth as clockwork. So coffee, beer and wifi were sorted, ensuring happy campers!

Some of the other things we did to keep the organisation on track leading up to the weekend were:

  • Set up a Basecamp project, which may have been overkill but proved to be invaluable
  • Distributed responsibilities – e.g. finance, sponsorship, ticket sales, coffee, beer – to various members of the crew
  • Held regular virtual meetings via IRC, capturing the logs in Basecamp for reference
  • Used Eventbrite, Paypal and a joint bank account to manage ticket sales
  • Sent messages and encouraged communication via the Railscamp Google Group
  • Sent messages via the @railscamp_au Twitter account
  • Took advantage of the skills of Tim Lucas and Daniel Bogan to get the t-shirts designed and ordered
  • Created a simple Rails app that, amongst other things, enabled sending emails to participants via MailChimp and facilitated printing lanyard inserts
  • Organised buses to transport campers between Gold Coast airport and Lake Ainsworth
  • Created a Rails Camp 9 Twitter list
  • Organised a welcome BBQ (thanks Zubin) for those who arrived early enough on the Friday
  • Thanks to Elle and Gabe Hollombe, provided an Ideagora app for sharing interests, projects and talks

Running the event

One of the wonderful things about an unconference such as Rails Camp is that, once it starts, it is largely self-organising. The 146 participants of Rails Camp 9 decided how they would spend the weekend. Many chose projects to work on and talks to either present or listen to. Some simply appreciated the opportunity to socialise amongst like-minded people. And, of course, there were games of Werewolf to be played.

Rails Camp 9 Hacking

As an organiser, once the camp had started, I found my role was largely to be alert to the possibility of requests for assistance. Whilst this did keep me reasonably busy I did have the chance to catch up with and meet lots of Ruby people from around Austalia and New Zealand. I also managed, thanks to Phil Oye, to remember how to use Bananajour so that I could submit a couple of patches to Ideagora. And, there was one particularly epic game of Werewolf (thanks Carl) to remember.

Thanks to our Sponsors

A wrap of Rails Camp 9 would not be complete without thanking our sponsors. So, on behalf of the organising crew, I extend a big thank you to:

Future Australian Rails Camps

Another heartening thing about the Australian Rails Camp community is that by the end of one camp a volunteer invariably steps up to take responsibility for organising the next camp. Happily, Sebastian von Conrad did just that at Lake Ainsworth, agreeing to take possession of the virtual baton to ensure that Rails Camp 10 happens near Adelaide.

Not only that, there have already been discussions about the possibility of Rails Camp 11 in Queensland and Rails Camp 12 in Tasmania!

Tags: rails railscamp unconference | Comments (0)

Committed Stand-Ups

May 13th, 2011

How effective is your daily stand-up meeting? Is it energising the team or does it have a “going through the motions” feel to it?

In his book, The Agile Samurai, Jonathan Rasmusson recommends that each person tell the rest of the team:

  • What you did to change the world yesterday
  • How you are going to crush it today
  • How you are going to blast though any obstacles unfortunate enough to be standing in your way

It’s a change of emphasis that I think is worth trying. As Jonathan says, it is a demonstration of commitment to the team and “dramatically increases the chances of you getting it done.”

However, if being so positive feels uncomfortable or forced, this probably indicates that there are other problems affecting the team’s morale that need to be dealt with.

Tags: agile standups | Comments (0)

On Agile

April 27th, 2011

Bingo

Before you turn off, I realise that the term “agile” in the context of software development has been overused to death. My aim is not to write a buzzword-compliant essay. Rather, having endured many projects run under the misapprehensions of outmoded assumptions and having endeavoured to get the best out of so-called “agile” approaches to software development, I feel I have a worthwhile perspective to offer.

Different Perspectives

I think the crux of discussing “agile” is to acknowledge the differing points of view of the developer and the customer. This may seem obvious but, in my view, it’s a crucial point.

The Developer’s Viewpoint

As a developer, I’ve had a lot of time to reflect upon shortcomings of the more traditional approach to building software. I well remember attending in-house courses on “Requirements, Planning and Estimating” and “Project Management” at IBM, early in my career, in the mid-80s. At the time there was much emphasis on documentation. The requirements, the external design and the internal design all had to be documented and formally approved before one line of code was written.

To be fair, in some cases, projects were divided into stages but, by and large, my experience of project management in the 1980s and 1990s was dominated by the waterfall model. The idea of iterative development had yet to hit the mainstream.

Central to the problems of the waterfall model is the difficulty in estimating accurately when grappling with initial requirements and designing an application. Usually, throughout the course of a software development project, understanding of requirements and design changes significantly. So it is very unlikely that an accurate estimate can be given at the outset. No doubt this is why estimation games have been well practiced in the software industry.

As described in Jonathan Rasmusson’s excellent book, The Agile Samurai, all projects are bound by four variables: Time, Budget, Quality and Scope. The problem with basing a software development project on the waterfall model is that this often leads to an expectation that all four variables will be fixed. Given the inherent difficulty in accurate software project estimation, this is obviously unrealistic.

The agile approach addresses these problems by treating scope as the only variable and delivering software in frequent iterations. As shown in Extreme Programming Release Planning, which I first experienced about ten years ago, requirements are broken up into “user stories”, each of which is estimated and prioritised.

A key point is the unit of estimation. In the agile approach, it is not a measurement of actual work hours which may be translated into a monetary amount. In original XP planning, the unit was an ideal week. The name of the unit may be arbitrary. It doesn’t matter what you call it. What really matters is that each user story is estimated relative to others. This enables allocation of user stories to releases more accurately as the developers discover roughly how many units they can complete in each iteration. Also, since iterations are kept small in duration, user feedback allows timely modification and exploration of user stories that will comprise subsequent iterations.

All the elements of agile planning make sense to me as a developer. However, a customer, not necessarily used to software development, may be less easily persuaded.

The Customer’s Viewpoint

As a customer, speaking generally, I expect value for money. For most goods and services I am used to having a fixed-price quotation honoured for clearly agreed specifications.

Why should I expect any different for software development? If I ask how much it will cost for a specific software application to be built, why should I not expect the supplier to let me know in advance?

What’s this talk about estimating requirements in terms of arbitrary points? And what’s this I hear about pair programming? Do you seriously expect me to pay for two developers working on the same piece of code at the same time?

At this point I should emphasise that I am trying to think of various customers that I have dealt with over the years and put myself in their shoes. As I do that I am reminded that these customers have had various degrees of acquaintance with the complexities of developing software. I think that this gets to the heart of the matter. As a customer, if there is a good reason why I should not expect a fixed-price quotation then the developer must be able to explain that reason clearly to me.

After all, the customer is paying the bills. Any argument for embracing an agile approach must be compelling in monetary terms.

Bridging the Gap

When we consider the agile approach to software development, I think it is clear that there is a gap between what proponents see as benefits of this approach and the expectations of many customers.

If you’re still with me, you may be expecting that at this point I will reveal my brilliant answer to the conundrum. I am sorry to disappoint you. If there was a brilliant answer I am sure someone else would have capitalised on it before now. Obviously, it is critical for an agile software developer to clearly describe to their customer at the very beginning of an engagement what to expect. As with so much in life, setting expectations is crucial. It is a lesson I need to keep reminding myself.

Every customer is different. Every relationship will differ. And relationships change over time. I forget where I read it, but the essence of the quote was that “in a good agile relationship, trust improves with every iteration”. I like the spirit of that statement.

It is also important to allow your approach to evolve. As Ben Webster said recently, “embracing as many mistakes as possible on the job” is a useful resource as an agile practitioner.

In Conclusion

To borrow from The Mythical Man-Month by Fred Brooks, there is no silver bullet. Making the most of the agile approach to software development requires an individual response. If you would like to share elements of yours, I look forward to your comments.

Tags: agile estimation planning | Comments (2)

Maintaining a Legacy Rails App

April 5th, 2011

Last night I deployed a new release of a Rails app.

Having deployed apps built with Rails 3 or at the very least Rails 2 apps using Bundler, the experience of deploying a Rails 2.3.5 app left me with a keen desire to at least bring this app up to Rails 2.3.11 with Bundler.

One of the delights of last night’s deployment was having to update RubyGems on the target machine. Usually this is as simple as:

gem update --system

That is, unless you are forced to upgrade to a specific, old release of RubyGems. Being at Rails 2.3.5 with this app, we were in this situation.

Speaking of “not exactly state of the art”, the version of Ruby on the target machine is Ruby Enterprise Edition 1.8.6.

Obviously, the preferred option would be to upgrade to Ruby 1.9.2 and Rails 3.0.5 forthwith.

However, it’s not my money that will be funding the upgrade. First steps first. I’m aiming for the following path:

  • Rails 2.3.11 with Bundler and latest compatible gems.
  • Ruby 1.9.2
  • Rails 3.0.5

Wish me luck!

Tags: ruby rails rubygems legacy apps | Comments (0)

Reflections on YOW 2010 Conference

March 4th, 2011

Introduction

Perhaps I needed time to reflect on such a wonderful conference.

Ever since the YOW! Developer Conference in Melbourne last December, I’ve been meaning to share some of my impressions. It may be three months down the track but I’m finally getting around to it!

Five Favourite Talks

The conference deserved praise for many reasons but I’ll narrow it down to some brief reflections on five talks that impressed me for different reasons.

Neal Ford

A small percentage of Rails developers have the opportunity to work in teams developing large, enterprise-scale apps. A not insignificant number of aspersions have been levelled at Rails, claiming that it can’t scale. So it was refreshing to hear Neal Ford talk about Rails in the Large, based on his experiences leading a team that has built arguably the biggest Rails app in the world.

Neal’s invigorating talk reviewed the lessons learned in the project such as effective testing strategies. For example, he unsurprisingly impressed the audience by relating how, with the help of UnitRecord, the team was able to run just under 9,000 tests in 41 seconds! Neal described other testing techniques as well as strategies for aspects such as continuous integration, effective communication in a development team and automation. Crucially, he emphasised ingenious ways that the team kept a sense of fun to the fore at all times.

There were many more nuggets that this talk contained. If you get the chance to hear Neal speak I thoroughly recommend it.

Keynote by Guy Steele and Richard Gabriel

I cannot find the words to adequately describe the gem that was the 50 in 50 keynote by Guy Steele and Richard Gabriel.

So I’ll keep my reflections brief. Wise, well-informed and witty, this talk by Guy and Richard was rich in its perspective of the often weird and wonderful paths that computer languages have followed over the last 50 years. A perfect tonic to prepare us for the conference party!

Eric Evans

Getting a message across through dry humour is a gift which Eric Evans demonstrated amply in his talk entitled Strategic Design: Avoiding Responsibility Traps.

Eric led the audience through a story about several sub-optimal scenarios that can eventuate when a software development team is faced with the challenge of augmenting a legacy system. His key messages included the importance of distilling the core domain, using context mapping and building an anti-corruption layer. Eric’s parting recommendations were to:

  • look for assets in the legacy
  • work in the core domain

And, of course, to make use of his book, Domain-Driven Design, even if only to read Chapter 14.

Jason Yip

I love the tagline on Jason Yip’s blog: “Making software is about making people.” So true.

Jason’s talk, Row Together, Row in the Right Direction, Row Faster: Improving alignment and throughput in software development, tuned into vital aspects of collaboration, whether at the level of a team, department or organisation.

After setting the stage with a few amusing but relevant anecdotes, Jason expanded on his contention that groups of people maximise their collective effectiveness by:

  • being aligned and coordinated;
  • sharing the same direction and vision;
  • improving productivity by mastering skills

Jason emphasised that what he had presented was intended to be more of a useful metaphor than the result of rigorous analysis. It would be interesting to see Jason’s observations validated by quantitative research. Meanwhile, I’m glad I listened to Jason’s typically thoughtful, entertaining and thought-provoking talk.

Dan Ingalls

As someone who, when first exploring object-oriented programming cut his teeth on Smalltalk, I was fortunatate to be able to listen to Dan Ingalls reminisce about his Forty Years of Fun with Computers.

It was amazing to listen to Dan speak so humbly about his experiences when they included working with Alan Kay and attending lectures given by Don Knuth, not to mention being the principal architect of five generations of Smalltalk environments. Regardless of all his achievements what shone through above all was his enduring sense of fun. I won’t attempt to describe the specifics of Dan’s talk. Suffice to say it was a privilege to be there and a special way to end the conference. If you get the chance to hear Dan speak, grasp it!

Dan concluded his talk with this wonderful advice:

“Keep things simple, general and flexible and you’ll have fun.”

A Conference to be Recommended

So there you have it. Five of my favourite talks from the YOW! Australia 2010 Developer Conference.

Belated congratulations to Dave Thomas and Lisa Cumes from Bedarra Research Labs for attracting such a superb collection of speakers covering a broad range of topics. The whole conference was a blast and I certainly wholeheartedly recommend the 2011 edition to other Australian developers.

Tags: conference yow | Comments (2)