"My sources inform me..."

I recently heard a rumor from trustworthy sources that Accenture Finland is investing in training willing technologists in Ruby and Rails, and [wait for it] that they're looking for project opportunities where to apply said technologies. This can only be a good thing--if the big players are suggesting customers to use Ruby/Rails for certain purposes, that means us smaller players have easier time convincing those same clients about the value frameworks like Rails and dynamic languages like Ruby can deliver!

Here's my short account on XP Day 2005. I realize the conference was exactly a week ago and my blogging this is hopelessly late according to blogosphere standards. What can I say? Busy times...

Monday

Tim Lister kicked off the conference with a keynote that was both inspiring and entertaining--I wouldn't expect any less, of course. I had a chance to exchange a couple of words with Tim before the conference. It's interesting how all the "big" names in software development seem to have visited Finland in the early 90's but few are around nowadays.

I also talked with Tom Gilb right after the keynote. He mentioned feeling awkward being almost the only person in the conference wearing a tie. Tom used to work at IBM back in the "dress code days." I'm just glad they didn't have dress codes anymore back when I joined Accenture in Finland.

Somewhere along the way, I mentioned the ferry conference we've been talking about on the Agile Finland mailing list and Tom said he'd be delighted to attend. In fact, he wasn't the only one who immediately "lighted up" after hearing about the concept. We'll have to look into whether such a conference could be put together. It'll require certain legal stuff in place before we can commit to venue reservations etc. and coordinating registrations from two countries for what's essentially two separate cruises having some overlap is definitely going to be a challenge. We'll see.

This year's XP Day was also a chance to meet some virtual buddies in person. Clarke running a session right after the keynote made it easy for us to actually shake hands even though the plan about sitting down for lunch didn't actually realize. Maybe next time...

Next, I attended Rachel and Romilly's session on agile thinking tools. In practice, that more or less meant mind mapping. I've tried mind mapping before for structuring my thoughts on a topic for a presentation, for example, but I haven't really picked it up as a regular thing. There are really good things about the technique and I know some people who are actively using mind mapping at work. Maybe I'll give it a shot again, soon. Rachel and Romilly also introduced De Bono's concept of thinking hats. I'd heard of the technique before but hadn't really tried it out. It's hard. It really is. At least for me. But it also helps you bring out stuff that matters but that you'd otherwise missed. (Related: Simon Baker has posted pictures from the session)

I also happened to bump into Joe Schmetzer who recognized my name from having read my CruiseControl articles. It's always a pleasure to learn that someone has actually read my stuff and found it useful. Several people also mentioned recognizing my name from being "active in the XP list," which is a bit odd since I feel like I haven't posted more than perhaps 1 message a month during the past year or so. Too much stuff to keep up with. My gmail account says I've got 1800 unread discussion threads under the "XP Yahoo! group" label...

In the afternoon, Steve Freeman and Andy Pols did the "Getting to know your customer" session, which was a more or less direct continuation from Rachel and Romilly's topic of thinking tools. We went briefly through the cynefin sense-making framework, did a butterfly stamp exercise, and then moved on to Luke Hohmann's innovation games. A bunch of very useful tools. Some of them are arguably a bit "out there" and thus perhaps not suitable (as such) for all contexts, but they're certainly packing a punch and I'm sure I'll be able to apply some of the techniques in actually talking with our customers.

I also managed to meet up with plenty of old friends such as Giovanni, Brian, Fred, Willem, and probably a whole bunch that don't come to mind right now. After the official program, we headed to the nearby Mudlark pub where we had a lot of interesting discussion, catching up, and drinking free beer courtesy of Finetix. I also met Daniel Poon, a live Smalltalk programmer who's actually doing Smalltalk for a living. Nice. And obviously he insisted that I should pair program with a smalltalker for a day and I'd learn the enormous advantage Smalltalk has over other languages (or should I say platforms?). I'm afraid that won't happen until someone decides to start running a Coding Dojo in Helsinki using Smalltalk ;)

Tuesday

Tuesday started with a keynote by William Gaver, a designer from the Royal College of Art. He presented a different and very intriguing talk about how a group of researchers have explored new ways of fitting technology into our lives through innovations like "floating table", "terrence the dog", etc. While the topic was rather far from software development, I did see certain connections between what the researchers were doing and how, for example, the Cynefin model suggests we act to resolve problems identified in the chaotic sector. Andy Pols has posted some links and pictures featured in Bill's keynote.

The first session after the keynote was Tom Gilb's "Quantifying Any Quality". Unfortunately, I left Tom's session without really knowing how to go about quantifying any quality. Tom did demonstrate how he could work together with a customer (a volunteer) from a vague qualitative "requirement" (more innovation) for a project to something measurable (increase in annual income) through a process of reducing the qualitative requirement into the customer's "real" needs (money).

While looking at Tom work the requirements was enlightening in itself, the problem is that this transformation is only half of the solution--the other half being, how to measure the resulting quantitative metric of "increase in annual income?" This question was clearly in the minds of many other attendants as well and someone actually did ask Tom what to do while we don't want to wait for 3 months to get the accounting numbers. Tom's answer: on a weekly level, follow progress through "number of innovations".

In summary, it was fascinating and teaching to see Tom dig out the stuff that matters from the customer and how he organized his thoughts on paper while doing that, but I remain unsure about how to really quantify any quality in a meaningful, feasible, measurable way. Later on, I came up with a follow-up question I eventually forgot to ask: how would one estimate the effort for a project of which requirements are expressed as qualities (referring to Tom's story about a company that "stopped doing features")...

Tom was also busy burning cds full of stuff for the audience, including a complimentary copy of his latest book, "Competitive Engineering." I did make a note of taking a peek at his book (especially the chapter which talks about quantifying any quality) even though--and largely because--I didn't get that good a picture of the techniques involved from the session itself.

Next, it was time for a session titled "Agile is ready for business, but is the business ready for agile?" by the BNP Paribas crew consisting of Fred Tingey, Marc Kennedy, and Nick Price. Theirs seemed a very timely topic for me, considering that we're currently working with several clients who are either feeling pains caused by the bottleneck moving after adopting agile methods or who are asking us for help in making sure that there will be as little "pain" as possible (prevent pain from being created in the first place).

In practice, the value I got out of the session was something completely different. We split into groups, each group taking the perspective of a specific part of an organization and brainstorming the kind of obstacles that particular stakeholder can have with agile methods. It was a useful eye-opener, highlighting things that everyone kind of knew already but that everyone also forgets to think about, all too often.

After lunch it was time for a bit of storytelling exercise using Fit with Steve Freeman and Mike Hill. Steve and Mike started the session with a very enlightening simulation of a developer and a customer working through a specification on the flip-chart, effectively formulating an executable specification, a skeleton for a Fit table. I applaude the simulation because that sort of things really convey the interaction and collaboration better than any diagram or writing can.

I only attended the session half-way, though (because I wanted to jump to Kevin's Jidoka session which was scheduled to start mid-way through), and what I managed to get out of Steve and Mike's session before the break pretty much circulated around the discussions we had in our table during the exercise regarding how to present certain conditions/assertions in the test document. Interestingly (or not) we spend most of our available time discussing whether we should add a certain column or not or whether we should write two tables instead of one, essentially trading duplication for readability. Finally, we ended up going for no duplication (which wasn't really such a bad idea even though that must sound awkward coming from someone who promotes readability every chance I get)...

To finish off Tuesday, Kevin Rutherford ran a session on Jidoka, which is one of Toyota Production System's two pillars (the other being Pull). Unfortunately Kevin was suffering from a chest infection and that, in part, affected his output. Kevin did manage to present the core idea in Jidoka very well, though, through his excellent story about a silk factory in Northern England (don't pass on faults) and the magnificent Chinese Whisper exercise.

XtC

After Kevin's Jidoka session and a brief closing where a lucky Exoftwarean (Dave) won a free ticket to next year's XP Day in exchange for a feedback form, it was time to head out to the other side of the river, to the Old Bank of England, the place where all the important stuff goes down. Yes, I'm talking about the Extreme Tuesday Club.

Needless to say, perhaps, there was much talking involved. I talked splash screens with Dresdner folks (can you imagine two agilists bragging about their splash screens for trader apps?), I talked pizza with the Grenoble US-expat league, continued the Smalltalk/Ruby/Python/whatnot language discussion with Willem, Daniel, and a bunch of other folks.

Before getting thrown out of the club room (yes, the pubs still close at night even though legislation would allow 24/7 service), we talked with Willem for quite a while about workshops, coaching, etc. It's always useful to share, confirm and compare experiences. We also talked about drawing. Willem mentioned about a psychologists in the US who had suggested making a conscious effort in getting back into a "lost skill" such as drawing. The whole discussion actually started from the flyers Willem had put together for a workshop, using silhouette-style graphics to give some texture for the otherwise text-dominant content.

Throughout the night, I managed to mention a number of people about a certain rails app I started writing on the night before my flight to London, creating more social pressure for me to actually get it finished. We'll see. I haven't yet touched it since that initial 2 hours :)

Getting thrown out of the Bank, we continued to the after party with Willem and Marko since the rest of the bunch bailed out early. Can you believe that? They were pulling lame excuses about work in the morning... (*rolls eyes*) We had a bunch of fun, a lot of it having to do with subordinating things to the constraint along the way to a pub between Angel and King's Cross :)

Getting thrown out again, some time around 3am, we tried to continue to the after-after party at the hotel bar. Alas, it was already closed so there was no option but to get some sleep before the next day's challenges. After failing to convince Conan, Duncan and others to come with us, we realized that the core of the whole XP community in Europe is rather small and actually consists of two Dutch people and a Finn. Or then our metric was a bit off. Some have suggested it's the metric.

Wednesday

Wednesday started, not surprisingly, by sleeping late, missing the breakfast by more than an hour, and meeting up with Willem, Marko, and Rob at King's Cross a bit after 11 o'clock. Since all of us had booked late flights (although some less late than others), the plan was to spend the day together doing tourist stuff, a.k.a. having fun.

As you might or might not have guessed, we planned our day with user stories, of course, while eating a fat breakfast at a little breakfast/lunch joint popular among local bluecollars. Most of the cards we came up with were actually constraints rather than stories (e.g. "catch flight"). We didn't quite manage to finish all stories, although the most important features (getting everyone on their respective flights) were completed in time.

During the few hours we had before having to head out to various airports, we talked about the usual stuff geeks talk about (women, and C64 computer games), continued the subordinating theme, walked quite a lot (even though one of the constraint cards said "not much walking"...), and ended up sitting in a pub (who would've guessed).

Cutting to the chase...

Stories completed:

• Buy a double-decker
• Take a photo of a double-decker
• Buy a gift for a 1 1/2 year-old girl
• Buy batteries
• Have fun
• Catch flight

Stories not completed:

• Buy vanilla coke (don't ask)

It was fun. Can't wait for next year! Although I have a feeling time will fly...

Do I feel a Gordon Pask Award heading towards Brad Appleton's direction? Perhaps. But maybe not for this Agile Six Sigma stuff...

Here's an excellent project management quote from Glen Alleman:

Not that other domains don't but here PM is
a line function equivalent to engineering,
not an add on to keep score.

Charles Miller blogs about good Java developers vs. excellent Perl hackers--and which one should you prefer to hire on your team. Actually, Charles quickly swaps in Python for Perl, talking about a "merely good" Java developer versus an excellent Python developer.

What's funny about the blog is how Charles jokes about the Java developer having to deal with the Python developer constantly complaining how "whatever feature you’re working on could be implemented better in five lines of Python." I'm actually involved with a project that uses Python as well as Java, and I think it's actually me who complains about Python (I'm a Java guy by background) and not the other way around. Yes, you read that correctly.

Whereas Python being a dynamic scripting language and all is nice, I can't help but feel that it's a compromise between the power and freedom of Ruby and the rigor of Java and the like. Yes, the list comprehensions are ok but what the heck is going on with tacking that "self" everywhere? :)

I digress. Back to business.

So, in his blog, Charles also says something I can't help but quote verbatim:

A great programmer may not crank out features ten times as fast as a good one, but they still may have that much performance benefit overall. For me, what gives great the edge over good is some combination of: attention to detail, which means their features will be more completely implemented with fewer incidental bugs, attention to design, which means they’ll leave the code in a better state than they found it, and inspiration, where they will find solutions to a problem that simply wouldn’t occur to other programmers. All of these have really, really powerful flow-on productivity effects for the whole team.

Let me repeat the part that especially struck a chord with me:

Attention to design, which means they'll leave the code in a better state than they found it, ...

Amen, brother! There are plenty of "good programmers" out there who manage to crank out bug-free software and come up with smart solutions, but I'm always most excited about seeing someone do the dirty work--cleaning up after whomever happened to code that particular function--without giving it a second thought. That's the kind of "good programmer" I'd hire for my team. Whereas it might be a nice-to-have in some contexts, living and breathing refactoring is a requirement for an agile project to deliver working software week in, week out, sustainably.