A reminder on how varargs work: essentially, they allow the last parameter of a method to be made of zero to many values of the same type.
For example, a method like this:

int max(int... values) {...};

is used by code like that:

int maximum = max(1, 2, 7, 0);
int maximum = max(1);

In truth, that form is only moderately useful in production code. It turns out that, on my projects at least, it is not so common for methods to be called with varying number of parameters. And in those cases, it is often acceptable to simply overload a method with more parameters.

There are however at least two cases where varargs shine.

One is in utilities classes. For example, Math.max() only takes exactly two parameters. Which comparisons between 3 or more elements very awkward. If a varargs had been used, Math.max(3, Math.max(1, 4)) would be written Math.max(3, 1, 4). Agreed, that does not happen that often. But it does occasionally.
(I must admit that I do not understand exactly why Math.max() has not been modified to take a varargs nowadays)

However, the biggest benefit, I believe, is in the writing of tests.
Tests tend to contain lots of variations in the values passed to the code under test. And it is critical to keep the clutter to a minimum.
For example, here is how a typical series of tests might look like

@Test
public void should_find_the_longest_name_for_a_single_user() {
	List users = new ArrayList();
	users.add(new User("eric"));
	assertThat(findLongestName(users), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	List users = new ArrayList();
	users.add(new User("eric"));
	users.add(new User("cecile"));
	assertThat(findLongestName(users), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	List users = new ArrayList();
	users.add(new User("cecile"));
	users.add(new User("eric"));
	assertThat(findLongestName(users), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	assertThat(findLongestName(new ArrayList()), is("eric"));
}

Of course, they can be made a bit nicer using the varargs in Arrays.asList():

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(asList(new User("eric"))), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	assertThat(findLongestName(asList(new User("eric"),
		new User("cecile"))), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	assertThat(findLongestName(asList(new User("cecile"),
		new User("eric"))), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(Arrays.asList());
}

However, the real goodness comes when writing our own builder method:

private static List users(String... names) {
	List users = new ArrayList();
	for (String name : names) {
		users.add(new User(name));
	}
	return users;
}

(side note: I like this type of methods to be private -so that I get notified when they are not used anymore- and static -mostly because they look nicer in italic, which makes it clearer that they are not part of the code being tested-)

which allow our tests to become:

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(users("eric")), is("eric"));
}

@Test
public void should_find_the_longest_name_when_shorted_is_first() {
	assertThat(findLongestName(users("eric", "cecile")), is("cecile"));
}

@Test
public void should_find_the_longest_name_when_longest_is_first() {
	assertThat(findLongestName(users("cecile", "eric")), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(users());
}

Tests become a lot shorter, consistent, and easier to read. In fact, at this point, it is worth grouping the tests (at least those that do not throw an exception) into a single one:

@Test
public void should_find_the_longest_name_for_a_single_user() {
	assertThat(findLongestName(users("eric")), is("eric"));
	assertThat(findLongestName(users("eric", "cecile")), is("cecile"));
	assertThat(findLongestName(users("cecile", "eric")), is("cecile"));
}

@Test(expected = RuntimeException.class)
public void should_fail_when_search_for_the_longest_name_with_no_users() {
	findLongestName(users());
}

Final note: I prefer not to group those builder methods into a general utilities class — I tend to duplicate them in each test class. One reason is that I prefer keeping much of the test code close together. Another is that I tend to change the name of the method from test class to test class to make the code more fluent. Also, I think that DRY principles are not as important in the tests as they are in the production code.

In fact, I feel it has been the best CITCON so far. I was a bit afraid of the large crowd (150 people registered, a similar number to Paris last year; I’m not sure how many showed up. 120, maybe?), but it turned out easier than expected to discuss with other participants. Also, and most importantly, there was a feeling of a higher level of experience than usual. Few talks about the basics of tests or Continuous Integration (and no “what’s the best CI server” session at all, thank God). Instead, it was “Advanced TDD”, “Share Pair Programming experience”, “Mobile Testing”, etc. All good stuff and, as usual, I just couldn’t attend all the sessions I wanted.

As a side note, there were also less talk related to competing programming environment. Only a few people introduced themselves as working in Java, .NET or another programming environment. I can think of a couple of reasons:

• Java is so overwhelmingly everywhere that there is just no point bragging about it anymore
• the .NET crowd (and possibly others) have given up on trying to make their work environments better. I didn’t attend the one “CI in .NET” session (there were no Java-specific sessions), but I was told that it was a slightly discouraging share of thoughts such as “it wasn’t my choice, but I want to make the best of it”, “I like .NET but the environment is just lacking” or “seriously, what do *you* guys do to implement CI in .NET?”.

In some ways, the Java world is also calcifying around some tools such as Maven (some contenders are barking at the door, though). But the feeling is that, by and large, things get done is a fairly productive way. (I’ll admit that I can be overly optimistic about this, considering that I am in a Java shop (Algodeal) where the incredible freedom helps us being particularly efficient)

Now, I was surprized that few mentioned up-and-coming languages such as Scala and Clojure. Are they just being lumped into the Java category? Was CITCON London the wrong area to find experts in them?

Other highlights of the conference include the venue. Thank you ever so much, Wendy, for opening the doors of SkillsMatter. You went out of your way. The location was fantastic, and the venue perfect for us. I especially appreciated the powerful wifi internet access, a rarity even in fancy hotels.
I also appreciated the fact that this area London has large pubs that can host all willing participants after the conference is over (this was frustrating in Paris last year, where bars can be small and especially crowded on Friday evenings). Too bad music can be so loud there, making conversations sometimes difficult.

A few things to remember from CITCON London:

• Narrative, by the good folks at youDevise is a new test framework/helper. They present it as a BDD framework, but I rather see it as a way to enforce readability in your test classes. I like the modest, KISS, approach too. Plus, it seems easy to extend. I wrote a quick sample here.
• Continuous Deployment was a big topic, as expected. There were few mentions on specific tools or techniques, but the feeling was that the practice was getting mainstream.
• Apparently, a big framework in the JavaScript TDD space is QUnit. The session had left a lot to be desired (I left mid-way, but I’m told the end was good), but it at least drove the point that TDD was getting common in JS.
• Again, I left with the feeling that we are not doing enough to generalize Pair Programming at Algodeal.

For CITCON 2011, there were many votes for Berlin. Sounds like a good destination. Again, it will depend on whether we can get a cheap enough venue there.

And what to do when you have 21 geeks with time on their hands? Why, predictions, of course! (I want to do it again this year, check out the Google Moderator page I’ve started)

We decided to come up with a number of predictions (and bet on them), some serious, some not, that would be verified at CITCON Europe 2009, the price being beer points. And, the losers will be named and shamed, while the winners will be glorified (at least until new predictions are made, and for no more than a year, whichever is earliest).

Here are the predictions, and the actual outcome (a couple of them were settled by votes at the closing session):

So, out of 14 predictions, we got 11 right, 1 wrong, and 2 undecided.
Now, you may think that the answers were straightforward. But you need to realize that, for each one of them, someone was willing to bet a beer against the consensus. In other words, at the time when the predictions were made, it was not clear cut.

In the interest of the bets, I shall now reveal the names.
Winners (Glory to Them All!)

• Andrew Parker (8 rights, 1 wrong)
• Eric Lefevre (that’s me) (10 rights, 2 wrongs)
• Guillaume Tardif (6 rights, no wrongs)
• Jean-Michel Bea (8 rights, 2 wrongs)
• Pekka Pietikäinen (7 rights, 2 wrongs)

Losers (Boo to Them All!)

• Julian Simpson (3 rights, 4 wrongs)
• Jeffrey Fredrick (3 rights, 6 wrongs)
• Paul Julius (5 rights, 2 wrongs) — PJ is still a loser, ‘cos he has been right on bets with small payoffs
• Tom Sulston (4 rights, 4 wrongs)

I have started a new series of predictions for CITCON Europe 2010. There are two steps:

1. suggest predictions & vote for the best ones
2. when predictions have been selected, vote

To actually win your beers, you’ll have to come to CITCON Europe 2010 (still unannounced).
Please check out the Google Moderator page to propose your own predictions.

If you want to the gritty details, I have a picture of the full spreadsheet.

As I write this, 3 days after the closing, I have still not fully recovered from CITCON Paris 2009. I have been very much involved in organizing this edition, so I would like to indulge in a bit of personal retrospective, mostly on the organization of the conference. This is basically self-reflexion; if that’s not your thing, you can leave. You won’t miss much.

Here goes.

What worked at the conference:

• we had more than 120 participants, which is in line with CITCON’s goals and the highest number ever in all 11 events. Also, it is very close to the number we had estimated ourselves.
• all the people in the waiting list have eventually been invited to join the main registration list; no one was left behind
• costs were well under control, especially thanks to the free use of ISEP’s classrooms
• we got significant money from sponsors; in fact, combined with the well-contained expenses, this event contributed hugely to settle debts from the past events
• quality of food was alright (especially for a free event)
• there were a number of well-known people, helping make this event special for other participants
• twittering was big; according to my feed on Google Reader, there were more than 300 tweets. Including quite a few from people regretting not to have come.

What could have worked better:

• there was not enough food. I think this is partly because the caterer is not a real professional. Even though we had given good estimates for the number of participants, I think that, as the person in charge of the student foyer, he was used mostly to students eating on a budget. If we use such a semi-professional in the future (likely, since we want to use more free venues such as universities), we would be wise to over-estimate the number of participants as far as food is concerned. Just in case.
• Even though we did arrange the chairs in the main room in circles, we left the other rooms as they were, theater-style. This didn’t help having involved discussions (as opposed to presentations).
• I’m wondering if we have not reached the maximum possible number of participants. One of the things that I really enjoyed last year was the late night drinks with the few that dared stay. This year, we were 30 or 40 at the end. Groups started to split up. Guillaume and I led a few to the Ti Jos bar and to the Caveau des Oubliettes. Although nice, it was a bit sad, as there wasn’t really a “closing the closing session” moment. We didn’t even get to do new predictions! (and settle last year’s bets, BTW).
• Some rooms were lacking a video projector. I wonder if it would be good investment for the Open Information Foundation to buy one of those small and inexpensive projectors that have appeared recently on the market

On a more personal note, the conference passed a bit like a blur for me. Despite using OpenSpace Technology, I still ended up as the contact person for many participants, suppliers and sponsors, which was distracting. Also, helping my brother with the filming didn’t help. I even managed to miss out on the (now traditional) “Is Scrum Evil?” session, which had been a favorite of mine last year.

I still had a great time. Met Antony Marcano and Andy Palmer from Pair With Us (they are hoping to join us at the Paris Coding Dojo sometime — looking forward to it) as well as Gojko Adzic, whose copies of book was given away to some lucky participants, and Jason Sankey and Daniel Ostermeier from Zutubi… Reconnected with many former colleagues and friends, too. I also attended a few sessions ;-)

Oh, and last but not least, I’m one of the winners from last year’s bets! What do I win? Well, beer, in theory. But, even better, I get to call PJ, Jeffrey, Tom, Julian and Yegor LOSERS for a year. Priceless.

Check out

• all my pictures from the conference (pictures by others there)
• all the blog posts by participants
• my notes on the session on Mock Objects
• my notes on the session on Faster Tests
• all the notes on the sessions

See you next year, in one of the five cities in our short list (Zürich, Copenhagen, Belgrade, Dublin, and Prague).

“Going nowhere fast” by Nathan

The session on Faster Tests (led by David) was interesting, at least to the extend that it was quite clear that we at Algodeal are not doing too bad indeed (Douglas Squirrel from youDevise is another one that seems to be quite cerebral about tests and builds).

By looking that the various options discussed to get tests faster, I think it’s fair to say that the only way to really speed up tests is by compromising their integrity, at least to a level. In a way, to make tests faster, you’ve got to face reality and move away from their ideal abstraction (very reminiscent of Joel Spolsky’s Law of Leaky Abstractions). The only question is: how confident are you that those (slightly compromised) tests actually test something useful?

This leads to the conclusion that we only keep long integration tests because it is difficult for us to really understand what’s going on. If we did have an excellent understanding, we would have unit tests instead. And, interestingly, as we progress in our project, we find ways to convert integration tests into unit tests. In other words, we better understand what’s going on.

Also, check out my notes on the session on Mock Objects.

The session on mock objects, mostly lead by Steve Freeman, was a bit messy but interesting. My colleague David got to show some of our code on the screen, which was scary and exciting (he felt the urge to fix some of the tests he had shown immediately after). Also, I think I finally understood the relation between mock objects and interfaces that Steve insists on.

See, I always thought that Steve was in favour in adding interfaces directly on top of concrete classes. For example, if you have a FileManager, you would also have a IFileManager.

Steve made more clear that the idea was to use interfaces to represent a role, or (more exactly) just one of the roles that a class has. That makes sense. But, to be honest, I still prefer to have a single role per class. So, no interfaces really needed.

I wish I had more time to talk with Steve. Maybe his coming book will have answers for me.

We chatted about a favorite topic of mine: how to expand the horizons for Agile. My point is mostly that the Agile crowd is mostly talking about basic issues in software development, including during the Agile 2009 conference. I fear that this my give the wrong impression to beginners (“how, so we only need to do this and that, and we’re agile? Cool!”) and even to seasoned practitioners (“this Agile thing is not addressing my needs anymore”).
I would much prefer that we talk more about complex problems, whether they relate directly to Agile or not. This can include technical discussions or more touchy-feely ones. As long as we are addressing difficult problems, we will be making progress.

I also want to see more cross-domains talks. Obvious domains are the heavy industry (I won’t need to remind how influential Toyota has been to the IT industry) or performing arts. But that could also include things such as Behavioral Economics.

Or not. I don’t know for sure. However, I do know that we should be taking more risks. And stop presenting Introductions to Retrospectives for the upteenth time.

At the end of the talk, I mention 2 things for further reading. Here they are, plus a bonus book that I’ve just read:

• Implementation Patterns, by Kent Beck
• Rands In Repose, a blog on technological culture and managerial aspect of life in an IT firm; posts are not frequent, but very interesting (and long)
• bonus track: The Logic of Life, a book by Tim Harford; this is very much in the style of The Undercover Economist (his previous books, which I enjoyed a lot) and Freakonomics (ditto)

The podcast is available in French on the Vox Agile site.

Amongst the activities that might interest fans of the Java:

• the Programming with the Stars contest where pairs of developers wll be demonstrate their programming skills in front of a panel of three wise men. The language is up to the developers.
• the Developer Jam stage, particularly dedicated to programmers
• another stage that might be of interest is Tools For Agility
• Java developers might also relate to the Agile developer, Architect and Developer personas

Here are a few sessions with Java either as the main topic, or as the language used for demonstration:

• Emergent Design & Evolutionary Architecture with none other than Neal Ford
• Scala: Object-Oriented and Functional Programming for the JVM by Dean Wampler
• How to make your testing more Groovy by Paul King and Craig Smith
• Agile AJAX: The Google Web Toolkit Experience, presented by Daniel Wellman and Paul Infield-Harm
• Creating Habitable Code: Lessons in Longevity from CruiseControl, with Jeffrey Fredrick and Paul Julius
• Java and Ruby Tools for Code Quality, by Steve Hayes

For some other sessions, Java is not central, but will be at least mentioned:

• SOA and Color Modeling by Daniel Vacanti and Stephen Palmer
• Coding Dojo: Enhancing Legacy Code, presented by Guillaume Tardif and myself
• Executable requirements: BDD with easyb and JDave (will also mention Groovy), with John Smart and Lasse Koskela
• Clean Code III: Functions, with Robert Martin
• BDD clinic – the doctor is in, by Pat Maddox and Elizabeth Keogh
• Malleable Code:  How Tests Improve Production Code, by Eric Anderson
• Back to Basics – Writing Expressive Tests Without All The Wizardry, with Rod Coffin
• Test Driven Development in Java: Live and Uncensored, with Ben Rady
• Acceptance Testing Java Applications with Cucumber, RSpec, and JRuby, with Dean Wampler and Aslak Hellesøy
• Java Power Tools – getting it all together, with John Smart
• Applying Agile Development Practices to Atypical Technologies, from Scott Dillman
• Mission Impossible: TDD and JavaScript, by James Suchy
• Leveraging Maven 2 for Agility, with Tim Andersen and Luke Amdor
• Automated deployment with Maven and friends – going the whole nine yards, from John Smart
• Growing Object-Oriented Software, Guided by Tests, by Steve Freeman

Check out the entire program on conference site!

Update (06/08/2009): should have mentioned that the Cast Codeurs podcast pretty much have the same information in French.

First, CITCON will be represented by Lydia Tripp and myself during the Freshers’ Faire at the Ice Breaker. Watch out for the CITCON easel pad… and world-famous t-shirts ;-)

CITCON alumni are now a big crowd (there are more than 750 mailing list members, and presumably many more attended the CITCON events). Many of them will present at the conference

• What does an Agile coach do? by Rachel Davies
• Coding Dojo: Enhancing Legacy Code by Guillaume Tardif & Eric Lefevre-Ardant
• ATTD In Practice, by Elisabeth Hendrickson (with Pekka Klärck)
• Continuous Integration of the World, by Patrick Debois
• Executable Requirements: BDD with easyb and JDave, by John Smart
• Growing Object-Oriented Software, Guided by Test, by Steve Freeman
• Telling Your Stories: Why Stories are important for your team, by Rachel Davies
• Automated deployment with Maven and friends – going the whole nine yards, by John Smart
• Build Engineer Bootcamp: Builds As Code, by Jeffrey Fredrick and Paul Julius
• Test Driven Development: Ten Years Later, by Steve Freeman (with Michael Feathers)
• Creating Habitable Code: Lessons in Longevity from CruiseControl, by Jeffrey Fredrick and Paul Julius
• Visual Management for Agile Teams, by Xavier Quesada Allue
• CI vendor cage-fight! by Tom Sulston
• How to be really awesome at Continuous Integration, by Tom Sulston
• Java Power Tools – getting it all together, by John Smart
• Debugging Pair Programming, by Matt Wynne
• Narrative Acceptance Tests – A Behaviour Driven Approach, by Antony Marcano and Andy Palmer
• Continuous Testing Evolved, by Ben Rady (with Rod Coffin)
• Test Driven Development in Java: Live and Uncensored, by Ben Rady
• Exploratory Testing (Framework) Experience, by Erik Petersen
• Agile testers toolkit, by Erik Petersen
• How to make your testing more Groovy, by Paul King (with Craig Smith)
• Agile Tool Hacking – Taking Your Agile Development Tools To The Next Level, by Paul King (with Craig Smith)
• The Agile CTO, by James Shore (with Diana Larsen)
• Metrics in an Agile World, by James Shore (with Rob Myers)
• Slow and Brittle: Replacing End-to-End Testing, by James Shore (with Arlo Belshee)
• Creating Agile Simulations and Games for Coaches and Consultants, by Elisabeth Hendrickson (with Chris Sims)

Also, Lisa Crispin is producer of the Testing Stage. And don’t forget that many more CITCONers will be presenting on the OpenJam stage, too! I know I‘ll be.

Lastly, I will be appearing a one of the contestants in Programming with the Stars! This means that I’ll be paired up with a “star”, then we’ll try to show our mad programming skillz and outperform our competitors. This is incredibly exciting but also very intimidating. Although I consider myself a competent programmer, I am certainly not the best, and the participants at the conference are not exactly beginners. Scary!

Check out the conference blog for an account of how Programming with the Stars went last year.

• Implementing Scrum/XP Practices using Team Foundation Server, by Tommy Norman : how various practices, including CI, can be implemented using Microsoft tool
• Build and Test in the Cloud – CI and Cloud Provisioning for Agile Teams, by Darryl Bowler: demonstration of CI practices, with the twist of using cloud-based systems
• Java and Ruby Tools for Code Quality, by Steve Hayes: using Continuous Integration as a platform for code quality tools
• Top ten secret weapons for performance testing in an agile environment, by Alistair Jones and Patrick Kua: according to the session description, there will be a connection with CI; that could be really interesting
• Continuous Testing Evolved, by Ben Rady and Rod Coffin: CT will be presented as an extension to CI
• Killing the gatekeeper: introducing a continuous integration system, by Francis Lacoste: an experience report on applying a CI system
• Continuous Integration of the World, by Patrick Debois: integration of production environment using CI
• Agile Source Code Management using Stories, Agile Workflow, and CI, by Damon Poole: real-world techniques that allow change management of features, and synchronization with source code
• Executable requirements: BDD with easyb and JDave, by  John Smart and Lasse Koskela: not directly related to CI, but it will mention how to integration BDD with your build process
• WANTED: Seeking Single Agile Knowledge Development Tool-set, by Brad Appleton and Peter Alfvin: this talk will, among other things, talk about applying agile practices, including CI, to non-code knowledge development
• Patterns of Agile Adoption Practices, by Amr Elssamadisy: CI is one of a set of practices that attendants will be asked to prioritize for discussion
• Large scale continuous integration, by Hannu Kokko: real life experience, with hundred of developers
• Automated deployment with Maven and friends – going the whole nine yards, by John Smart: how to automate deployment using Bamboo, JIRA and Nexus in a real-world multi-module Maven web application
• Build Engineer Bootcamp: Builds As Code, by Paul Julius & Jeffrey Fredrick: will discuss build systems, a topic very close to CI
• Removing Integration Delays with Collocated Whole Teams and Multi-stage CI, by Damon Poole: why and to implement multi-stage continuous integration in large distributed environments
• How to run 4.5 Million tests per day … and why!, by Mark Striebeck: how Google implemented a huge CI system for its own needs
• Enabling Agile Testing through Continuous Integration, by Sean Stolberg: how a CI system enables agile testing practices
• Continuous Integration: Your New Best Friend, by Howard Deiner: what CI is, and how is fits with unit tests, acceptance tests and development habits
• The 7 Deadly Sins of Almost Being Agile, by Bob Hartman and Richard Lawrence: never integrating is one of the sins discussed
• Creating Habitable Code: Lessons in Longevity from CruiseControl, by Jeffrey Fredrick and Paul Julius: not strictly about CI, but the tool discussed is the one that made CI popular, so this will be of interest to build experts
• Experiences Applying Agile Practices to Large Systems Development, by Harry Koehnemann: CI is one of the practices discussed
• Herding Cats: Managing Large Test Suites, by David Kessler and Tim Andersen: strategies to maintain automated test investments
• CI vendor cage-fight!, by Tom Sulston and vendors: 10 mins demos of all CI tools with representatives in the conference
• From Cowboys to Agilists – Organizational Change at Overstock.com, by Sean Landis and Kevin Steffensen: CI is described as one of the practices deployed to solve the software development crisis at overstock.com
• The Ogre and The Wimp: Clever Influencing Tricks – Help the Most Reluctant Teams, by Anda Abramovici: among other things, how to get the “I only run the build once a month” dev to do it every couple of hours, and how to get the “I only check in code once I’m completely done” dev to practice frequent check-ins
• Agile Infrastructure, by Andrew Shafer and Paul Nasrat: continuous deployment will be especially discussed
• Applying Agile Development Practices to Atypical Technologies, by Scott Dillman: CI is described as part of a case study
• How to be really awesome at Continuous Integration, by Tom Sulston and a panel of luminaries: discussion of the audience’s problems and questions
• Java Power Tools – getting it all together, by John Smart: use to how Hudson and other tools for a software development infrastructure

Phew! That’s quite a mouthful. Interestingly, there are many more talks listed here than I managed to get last year (and there are half as many talks this year). One reason could be that I was much more thourough this year, reviewing most of the sessions details — last year, I simply searched for keywords in the submission system.

To be honest, seeing as many sessions related to CI is rather a disappointment. I mean, CI is not a difficult practice, and you would think that many participants to Agile 2009 would be familiar with me. Plus, most sessions are introductions rather than advanced talks.

I guess I will content myself with Tom Sulston’s sessions (“Cage Fight” & “How to be awesome”).