It’s about a month since I attended XP Day 2004. For personal reasons I was thinking of missing it, but I am very pleased that I went. It was very hard to decide which sessions to attend; at any time there was at least two sessions that I wanted to attend.

David Snowden
The Key Note speaker on the Thursday was David Snowden; he is an excellent speaker with many thought provoking ideas on organisations, people, complexity, chaos, and using narrative. I decided to sign up for his afternoon masterclass, which proved challenging – too challenging. Some quotes (from memory, so at best paraphrases):

• When a measure becomes a target, it ceases to be a good measure.
• Hospital Matrons were examples of Strange Attractors.
• If the Singapore Navy closed the Mahjong club, the Intelligence could no longer talk to Operations.
• Humans use first fit pattern matching to make decisions; not rational or even best fit pattern matching.

Agile Deployment (John Birtley and Hubert Mathews)
They presented a quite brilliant (and with hindsight) bleeding obvious idea. Everone who hands over work to be deployed by others knows that it is nearly always a nightmare, and a pain to debug problems. Also it is impossible for development, or even staging, to match production environment.

The idea is to write automated tests for the environment. Test things like OS versions, Database versions, Java (if appropriate) versions, connectivity, database setup (tables, stored procs, population). I imagine that deployment problems not covered by the test suite will still occur, but these can be used to increase test coverage.

An Introduction to Goldratt’s Theory of Constraints (Clarke Ching)
Clarke gave quite a good introduction to TOC, which is essentially common sense (as opposed to common practice). Highlights were

• An amusing animation starring the construction worker from The Village People.
• An illustration of why multitasking is evil.
• An excellent analysis of The Waterfall as vicious circle (my interpretation) – the drivers behind adopting Waterfall and how this makes those problems worse.

I was not convinced by the quantify everything idea; I suspect it would be too easy to choose the slightly wrong metric and end up optimising the wrong thing. I did think that Tom Glib had some useful ideas. At coffee I discovered that he was generally not liked; I believe there’s some sort of “history” with Tom Glib and XP.

Understanding The Roots of Agility (Joseph Pelrine)
“If you’re doing XP as described in the White Book, you’re not doing XP”. This was an open presentation on the principles behind agile practices. If you understand the reasons for a practice you can apply it to your situation; if you doing it just because it is written that you should do it, you’re less likely to gain the benefits.

There was much reference to the Stacey, Certainty \ Agreement graph, moving towards chaos and back. There was a nice metaphor of “red green refactor” being like breathing out towards chaos and then back in towards simplicity.

He also discussed facilitation of project retrospectives with brainstorming techniques for moving from simplicity to the “edge of chaos” and back again.

Practices make Perfect Pair Programming (Andy Marks, Jo Waines)
Introduced as “a title in search of a presentation” this session kicked off with a brief presentation on choosing the environment for Extreme Programming and the importance of the coach, then on to the pair programming competition. In pairs we raced to complete the maximum number of (fairly low level and unit-like) acceptance tests in the allotted time. It ended in a dead heat with most pairs completing two out of six tests.

We took an early lead, being the only pair to (on my insistence) to start with the naive solution. Ater two tests we tried to refactor and then unfortunately noticed some utility classes that had been “made earlier”: we got bogged down trying to figure out how to use the provided classes and trying to work out the ultimate purpose of the code.

Some interesting lessons:

• if we’d stuck with naive solutions we would have won; I’m not so sure that this has wider lesssons.
• it took much longer to try and figure out how the utility classes might help us, then it would have been to ignore them. This resonates with thoughts I’ve been having on “not invented here” not been an anti-pattern after all.

• each team is close to a set of customers. This was given as the primary reason.
• Every five days 15 days worth of increments are released. Having the same numbers work on the code at the same time would introduce different (and perhaps more intractable) issues.

• the morning and evening video meetings (UK to USA, USA to Singapore, Singapore to UK).
• people swapping: at any time a number of developers on any team are “foreign”.

A couple of years ago I changed my mind about Checked Exceptions. It was Rod Johnson’s J2EE Design and Development that tipped me over to the other side, but I had been uneasy with them for a while: I had noticed that client code could rarely (if ever) do anything useful with supplier exceptions except log, wrap, and rethrow. My biggest criticism of checked exceptions is that they leak information, making polymorphism more difficult to apply. Simple example:

public interface UserNameHolder

{

  void addName(String name);

  boolean isUser(String name);

}

public class InMemoryUserNameHolder implements UserNameHolder

{

  private Collection names = new ArrayList();

  public void addName(String name)

  {

    names.add(name);

  }

  // Etc …..

}

public class DatabaseUserNameHolder implements UserNameHolder

{

  public void addName(String name)

  {

    Connection connection = null;

    PreparedStatement stmt = null;

    try

    {

      connection = getConnection();

      stmt = connection.prepareStatement(

      “INSERT INTO nameholder (user_name)  VALUES”);

      stmt.setString(1, name);

      stmt.executeUpdate();

    }

    catch (SQLException e)

    {

      // Oh Oh – what now?

    }

    finally

    {

      closeNicely(stmt, connection);

    }

  }

  // etc etcc

}

My rules
Currently I prefer the following rules

Runtime Exceptions
I tend to extend RuntimeException with UnrecoverableFailureException. This logs in the constructor (taking the throwing classes’ logger as a parameter). This way the exception is logged only on throwing: clients know that they need not catch and log.

public UnrecoverableFailureException(Logger clientLogger, String msg, Throwable e)

{

  super(msg, e);

  clientLogger.error(msg, e);

}

Checked Exceptions
Checked exceptions are best used to indicate uncheckable precondition failures. By uncheckable I mean preconditions that the client cannot be reasonably be expected to check before calling the method. For example we might have:

/**


	
Add a user to the system
	
PRECONDITION: !isUserNameAdded(userName)

*/

public synchronized void addUser(String userName, UserDetails details)

{

  if (isUserNameAdded(userName))

  {

    throw new IllegalArgumentException(“’” + userName + “’ has already been added”);

  }

  // etc…

}

public synchronized void addUser(String userName, UserDetails details) throws UserHasAlreadyBeenAddedException

{

// etc…

}

• Cleaner code. My code is less littered with try, catch, wrap an throws.
  
• Better encapsulation. I am no longer tempted to give away implementation details by propagating SQL\EJB\JNDI\etc.. exceptions to code that need not know.
  
• Easier polymorphism. Implementing interfaces is much less painful. The command pattern, in particular, becomes easier to use.
  
• More arguments. It is quite difficult to convince old-school Java Developers to use RuntimeExceptions. In my last team project I only managed to implement a general “unrecoverable” exceptions that was checked and nearly every method threw: as it was universally thrown it became a virtual runtime exception.
  
• Requires a single “message” loop mechanism. These runtime exceptions do need to be caught in order to display a general failure message, and it would be bad if that code became littered througout the application. In servlet environments this is easy to achieve with the Front Controller pattern . I haven’t tried (yet) in Swing.

• Rod Johnson’s interview on TSS: there’s a question on checked \unchecked exceptions halfway down.
  
• Andy Swan has a different view. He also has some more links to other articles.
  

For the past three years I’ve been trying to program J2ee following “standard” patterns: Stateless session facade, Entity Beans, Data-Transfer Objects. J2ee is strategically procedural. Stateless session facades tend to Blob antipattern.

It’s broken my feel for OO design. I need to get that back. This article on OO Design and avoiding accessors, that I picked up from Andy Swan’s blog helps.