Agile2007: Tuesday

Keynote: Reaching New Heights: Learning to Adapt is Essential

Susan Ershler

I’m not quite sure what to make of this keynote. Susan’s talk about achieving her twin goals of success in business and climbing the highest peaks on each continent (culminating in Everest) was interesting and well-presented, but came across to me as a motivational speech for business leaders, slightly tweaked to include a few agile themes. I’d have preferred to hear something more concrete from a thought leader in agile development (after all, there are a fair few of them here!)

Agile Developer Practices for Dynamic Languages

Paul King (ASERT)

Latest slides can be found here.

This seemed like it might be a useful talk, given that I’m an agile developer using a dynamic language! Some of the stuff that was covered I already knew, but there were still plenty of interesting points. Most of the examples given were in Groovy, with some in Ruby, but the principles applied equally to most dynamic languages.

The first part of the presentation was an overview of the differences between statically-typed languages (Java, C# etc) and dynamic languages (Ruby, Groovy, Python, Javascript and the like). Interestingly, Groovy allows you to use either strong or dynamic typing.

Some of the potential downsides of dynamic languages were mentioned, including weaker IDE support and the fact that it’s not always easy for new developers to dive into the code and see what it’s doing. The latter is certainly something we’ve come across in our team, where people joining the project took a while to figure it out, but I suspect it’s easier once you’re used to the language and/or framework being used (Rails’ convention over configuration helps here). It was suggested that sometimes compile-time type checking can lead to a false sense of security (it won’t always prevent class cast exceptions at run-time), and that some people feel they need more code documentation than with static languages (not something I’ve found personally).

We were given an example of problems that can be caused by “clever” code, where duplication was factored out of an adapter class by using method_missing jiggery-pokery. The issue being that you no longer get method name auto-completion in the IDE, or generated documentation for the methods. This is something we saw with the proof of concept Ruby Web21C SDK, where everything was generated at runtime fro the service descriptions, but there was no easy way of discovering the API. Someone made the point that if you’re going to generate methods using Ruby metaprogramming, you need to make sure you implement respond_to? to match.

There was some discussion of how far to go when refactoring to remove duplication, and Paul described an anti-pattern that he called “ravioli code” (as opposed to spaghetti code), where you end up with a huge number of tiny chunks of code, and the clarity of intent starts suffering.

After some discussion of metaprogramming, dependency injection (and why you might still want to use it in a dynamic language), mocks and behaviour-driven development, Paul mentioned a theory of his that the next step in BDD is disposable tests. His argument was that the mock expectation code ends up almost identical to the production code, so one could be generated from the other. I’m not entirely convinced, because I like the double-entry book-keeping aspect of tests, but it’s an interesting idea. He also tried to stir up a bit of controversy by claiming that “BDD is just a crutch for people who don’t have an expressive enough language”. He’s actually a fan of BDD, but the point was that if you could just execute the behaviour specification directly you wouldn’t need the extra step of implementation.

The final point was a warning that you need to think more about feature interaction when behaviour can be altered at runtime.

The One-Size-Fits-One Simulation

Tyler Jennings & Dave Hoover (Obtiva Corp)

Unfortunately I misjudged the target audience for this session. The first hour and a half were just an introduction to Rails, which was a waste of time for those of us who already use it. I’m not sure how many others in the room were in the same boat. I didn’t go back for the second half, so I don’t know what the toolkit they were presnting could do. I might download it at some point and have a play. Instead I went to…

Agile adoption at Google: Potential and challenges of a true bottom-up organization

Mark Striebeck

I was interested to hear what Google were doing with agile, particularly given the infamous Steve Yegge rant from last year. Turns out that as I expected there are lots of teams in Google doing various agile things, but no top-down imposition of a particular methodology.

They have a team of people who help drive agility across the company, but not as their full-time jobs. It sounds like a lot of the ways Google work are pretty agile anyway, but they’ve also concentrated a lot on automated tests and continuous integration. These are the two main things I think underpin agility, which is why I like XP with its concentration on technical practices far more than Scrum. I wonder whether we at BT have focussed enough on these areas in its attempt to transform ourselves into an agile organisation – when our team started introducing XP we started with unit testing, and that seemed to work well.

One idea that I thought might transfer well to BT was the “agile safari”. This involved creating a register of people and teams using various agile tools and techniques, and allowing people to go and watch them “in the wild”. I suspect this would give a much better idea of how something worked than just reading about it or attending a tutorial.

One of the slides described “bear and ice-cream” events – the mind boggles.

Agile Alliance Members Meeting

Refreshingly quick and to the point, followed by a pub crawl. That’s how all AGMs should be run!

Incidentally, one of the bars on the pub crawl turned up three firsts for me: having to go down to the basement in a lift to get to the toilet (or I should probably say “in an elevator to get to the bathroom”), a paper towel dispenser that reeled out a towel when you put your hand under it, and (last but not least) drinkable American beer!

[tags]agile2007, washington[/tags]