casperfabricius.com

I have a great class in school called Agile Methods, but while our teacher keeps the lessons interesting by letting us discuss a lot, I find learning about agile development really inspirational when I get the opportunity to hear about actual agile development projects from real-life practitioners. I’ve had two such opportunities recently and have met Obie Fernandez, a Rails and agile practitioner from ThoughtWorks, and Ole Jepsen, freelance agile consultant and co founder of Agile Project Leadership Network.

When Obie Fernandez was in Denmark to speak at JAOO, he also met up with a bunch of us from Copenhagen Ruby Brigade at a café in central Copenhagen. While most of the evening was spent completely relaxed just talking, Obie also gave his presentation from RailsConf Chicago, which I missed when I was there – glad I got the chance to hear it in my own hometown.

The presentation was mainly a collection of case stories about projects, where ThoughtWorks has successfully used Ruby on Rails and agile development, with a lot of good points mixed in. To be honest, I can’t recount too many of these points, since Jesper Rønn-Jensen kept buying rounds of drinks to everyone and it was very late in the evening, but I think most of what he said related to Rails can be found in his own summary.

I don’t think the actual presentation material can be found online, since it contains information about clients that’s not 100 % cleared, and it’s a pity, since a lot of what I got out the presentation was from seeing the images of real developers working on real agile development. When I read texts by Kent Beck, Jim Highsmith or some of the other agile gurus, I keep thinking that it sounds almost to good to be true. That no one could actually be doing this stuff for real, because it is just so wonderfully different from how we normally develop software. That’s why it’s nice to see images of people pair programming or having stand-up meetings, while stories on post-its hangs on the whiteboard in the background – people are doing this!

Now, two valuable things I do remember Obie saying, are that:

1. The only really good way to do pair programming, is have a setup with one computer, two mirrored screens and two sets of keyboards and mice that works simultaneously. This way none of the two developers has to sit and twist their neck to see the screen, they can select their own distance to each other and most importantly; they can switch between the coder and observer roles instantaneously. (This later made me think of how ironic the image on the front page of www.pairprogramming.com is.)
2. Traditional unit testing is not a very good fit for many Rails-applications, at least not if they are basically just CRUD-applications without any advanced business logic. This is due to the fact that ActiveRecord – which does the actual crudding – is already thoroughly tested, and that mainly controllers and user interface is added. For this reason, Obie recommended Selenium as the way to test your application, or – better yet – as a way to do test driven development. Selenium allows you test your user interface and application flow in an automated way through your browser, using JavaScript to control the tests.

Ole Jepsen, a Danish expert in agile development (which I don’t have a picture of, so I put myself in instead – just imagine that I’m talking notes while Ole is talking), gave a lesson at my Agile Methods class in a very agile way. After a short introduction of himself and his view on development, he asked us – the students – to come up with subjects about agile development we wanted him talk about. Then each of use got three votes, and the subjects where prioritized after number of votes. “These are our stories as you – the customers – has prioritized them, and I – the supplier – will try do as many of them in this time box as possible, starting out with the most important.” Ole said. Although I have pretty comprehensive notes, I will only dig into what I found was Ole’s most important points:

Pitfalls of agile development in practice
Just like waterfall methods doesn’t work like the text books say they will (at all!), agile methods of course also have their problems and pitfalls when you take them out of (say) Kent Beck’s comfortable descriptions and into the Real World^TM. Ole had an example from a big Danish telecommunication company, where a project which had failed several times, switched to use agile methods (“it has to hurt before they go agile!” was another of Ole’s points) – but not without problems:

• The customer (that is; the user of the system being developed) and the developers do not automatically communicate well, just because you put them in the same room. In this project, the customer and the lead architect held long meetings where customer explained the problem domain. Then the architect would spend two days writing Word documents and afterwards show them to the customer (which was in the same room), asking: “Is this right?”, and would get the answer: “No no, that’s completely wrong!”. In the end, the project manager had to ask the customer to take responsibility of really explaining the needs so the developers could understand it, and the developers, in turn, has to really listen.
• The project was planned in three main iterations, and near the end a fourth was added to catch up with postponed stories. After each iteration, a demonstration was done for the customer so they could see the progress. However, when the third iteration was nearing its end, the developers on the team persuaded the project manager to skip the demonstration, because work at that point was very hectic to finish up the project. They skipped the demonstration, but as a result; the customer started asking questions: Had they made progress? The point is; that in order work without a specific requirements specification, customer and supplier has to trust each other, and the customer has to be able to track the progress.

When go agile, and when to use waterfall
Ole explained that many people like to view the options for choosing a development method as two extremes:

• A large, predictable, complex project where requirements can be specified up front: Waterfall
• A smaller, dynamic (often web-) project: Agile

In Ole’s experience, though, there are no projects that won’t benefit from agile methods one way or another, while there are projects that will just never work with a waterfall model, because requirements are changing all the time. He also pointed out that if your project might fail, it should fail as early as possible.

Architecture in agile development projects
One of the big concerns of experienced developers considering going agile, is what happens to the architecture of the system being developed. Traditionally, one or more architects have laid the groundwork in designing the entire object model before the programmers where allowed to begin their part of the work. A traditional architect would consider it an embarrassment if his design has to be changed because of flaws or unforeseen things, but agile development does not allow much time for BDUF (Big Design Up Front).

The argument against BDUF is another acronym; YAGNI (You Ain’t Gonna Need It), which stresses the point that in trying to make a design that covers any conceivable aspect of the system, you are actually wasting a lot time designing – and often also implementing – stuff that will never be used. However, Ole explained, agile methods are in no opposed to architecture, it is just that the architect design, drawings and diagrams becomes less important, while the architects themselves becomes much more important.

Some agile practitioners are of the opinion that no dedicated architects are needed at all; all programmers are architects and visa versa. The purpose is that everyone “owns” the entire code base, so everyone is capable of making changes anywhere. Ole, however, does not like the idea of everyone making architecture decisions jointly – he prefers that a chief architect makes the final decisions and is responsible for keeping the design consistent and clear.

The above is just a fraction of all the exciting stuff I’m learning about agile development at the moment, and remember: You are not agile just because you code ad-hoc without planning your stuff in a code-and-fix way. Agile development requires both discipline and experience.

Anyway, I’m off to London for the next week and I’m not bringing my laptop, since I’m afraid of something happening to my precious, yet fragile Macbook Pro – so I’ll be offline for a week…

We felt lucky, the 20 of us from Copenhagen Ruby Brigade who had taken the time to show up for the third gathering of Rails enthusiasts in and near Copenhagen, this time hosted at my company; Kraftvaerk. Not only had open source guru and Ruby for Rails author David Black decided to join us for the evening, having taught a workshop in Malmö two days before; but when a little later no other than our own Rails creator and community front figure David Heinemeier Hansson (DHH) stepped in through the door, we started wondering whether this was really just a humble user group meeting – or RailsConf Copenhagen!

Not only did DHH willingly answer all questions we could come up with, he also showed us his demo from his keynote at RailsConf in London, including some pieces that hadn’t been ready for the conference, and which we were probably the first to experience. It’s hard to take notes of guy writing code live on the screen, especially when he moves away from the planned demonstration into “I’ve never tried this before, but let’s see if it works!”, but I tried, and this article is my write-up of DHH’s answers and demos.

HAML
DHH gave a quick sample of HAML – HTML Abstraction Markup Language – a template language for rendering beautiful XHTML in an easy to read and write way, created and announced by Hampton Catlin at RailConf Europe 2006, and quickly acknowledged by DHH:

%html
	%body
		#person
			#details
		.phone_numbers
	%li = list_of(:people) &:names

What’s cool about HAML, DHH said, was that it kept you DRY, even when you are writing HTML. The % is used for normal tags, the # creates div tags with the given id and the . creates div tags with the given class. It’s even possible to mix in Ruby code and for example create a list.

Internationalization
Being in a room full of Danish programmers, it was only that natural that internationalization came up – especially since Jesper Rønn-Jensen has been working on a localization plugin, and as Morten Christensen pointed out; shouldn’t 5 or more plugins for internationalization indicate quite clearly that the Rails community craves unified support implemented in the core?

No, DHH answered, from the Core Team’s point of view, this means that people want to support and implement internationalization in a lot of different ways, and that there is no universal solution that will make everybody happy. Even inside the Core Team people can’t agree how it should be done. Although, DHH added, I can’t rule out that the 37signals needs internationalization, is the day that Rails get it.

Better scaffolding
Scaffolding has lured a lot of developers into the wonders of Rails, but really, DHH said, it has always had a lot of strange limitations, which made it nearly useless for doing any real stuff. Scaffolding continues to be primarily a teaching tool, but the new scaffold_ressource command makes a lot of things right, that was wrong in the old kind of scaffolding:

• Old scaffoldings required you to have a table created for the object you where creating scaffolding for – now a migration file that will create the table is automatically adde.d
• The old scaffolding let you choose the controller name – now you only get the specify the name of the model, and the controller is automatically added with correct pluralization.
• Inside the controller, the old scaffolding had a list action, but no index – now it’s the other way around, since the index is the correct action to use.
• The views generated by the old scaffoldings was almost useless, since they just looped through the columns in the table – now, each actual column gets HTML created for it.
• Aside from that, the scaffolding views are still ugly – by design!

In summary; the new scaffolding generator lets you create RESTful scaffoldings that you can actually build on top of, and all with a command like this:

./script/generate scaffold_ressource post title:string created_at:datetime body:text

Any action can respond in any kind of format
By adhering to the Simply RESTful conventions and using the respond_to method, we can make our objects in any format we desire, without having to write separate actions for each format. DHH was building up his classic weblog application, and wanted to implement an XML representation of the Post object that could be consumed by an external application:

def index
	@posts = Posts.find(:all)

	respond_to do |format|
		format.html
		format.xml { render :xml => @posts.to_xml }
	end
end

This code actually enables us to access the list of all posts in the ordinary RHTML format from the url /posts, but if we want the XML representation of the same list, we just add .xml; like this: /posts.xml. This doesn’t just work with XML, in fact it works with any kind of extension you add support for in your actions, as long as you also remember to add it’s mime type in environment.rb, as DHH had to do to support the CSV format:

# environment.rb
Mime::Type.register("text/csv")

Further, DHH recommended his plugin Resource Feeder for easy support of ie. RSS using the method render_rss_feed. Another cool thing added is the auto_discovery_link_tag method, which renders the appropriate tag to ensure that the RSS icon is shown in Firefox, Safari and IE7.

ActiveResource working like a charm
While no surprise to all the lucky ones that attended RailsConf Europe, I enjoyed seeing the visions for ActiveResource DHH explained at the conference in Chicago, being now brought to life and working like a charm. By letting a model inherit from ActiveResource::Base instead of ActionRecord::Base and giving it a url to feed of, DHH demonstrated that you can treat objects in an external API exactly like the ones in your own database. And not just reading part of CRUD, the whole package. Sweet!

If you are in Copenhagen or southern Sweden (or are willing to travel), you have a great chance to attend a free Ruby on Rails on workshop with the acknowledged Ruby expert, Rails writer and RailsConf organizer David Black this Sunday; September 17th, at 10.00-18.00 in Malmö, Sweden.

It’s the Swedish startup Polar Rose that are hosting the workshop, both to educate its own people in Rails technology, but also to get in touch with the Rails community in the region of Øresund. Nikolaj Nyholm, the CEO of Polar Rose and program chair for O’Reilly EuroOSCON, originally tried engaging David Black for a tutorial at EuroOSCON. David Black was however busy with a workshop in Amsterdam, but when that was cancelled, David was quickly redirected to Malmö.

In other news, Kraftvaerk, the company I work for, are hosting the next Copenhagen.rb gathering at Thuesday September 19th, and rumour has it that David Black might also attend this event, if he can fit it into his busy schedule – my fingers are crossed! :)

David Black (left) with Chad Fowler photographed at RailsConf 2006 by yours truly