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.

For more information see this article and the Cynefin website (currently under construction).. 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.

Tom Glib Tom Glib gave the keynote on the second day. His basic message was that anything can be quantified, and iterations should be geared towards improving a limited set of key measures. For example the goal might be to improve a system's intuitiveness: the measure might be the number of times a new user needs to consult the manual. I couldn't help but remember one of yesterday's maxims - when a measure becomes a target, it ceases to be a good measure. 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.

Around the World in 80 standups It always feels good to hear success stories, so this was a great final session to attend. WDS have introduced "distributed" XP with three teams working on the same code base in relay. The team's are located in Poole (UK), Seattle (USA) and Singapore: when one team finishes for the day, the next team takes over. Why bother? The problems are obvious, the advantages are

• 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.

WDS have put a lot of effort into making the distributed XP work, and they have had problems. Their key practices are

• 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".

Joseph Pelrine quoted Kent Beck thoughts on doing things that cause problems frequently: releases are traditionally a problem so the XP (Agile) approach is to release frequently; testing is difficult so we do more of it. I wonder if WDS have "solved" the handover problem by handing their work over every 8 hours. I suspect it must have a positive impact on the simplicity and clarity of their code.

Sunday, December 19, 2004 | Permalink | 0 Comments

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 .....
}

Ok. No problems above. But

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
}

Now we don't know what to do with our SQLException. Previously I would have added a generic UserNameHolderException; but that extra class would add no useful functionality. All the client can be reasonably expected to do is display a generic internal failure message. Now I use runtime exceptions; such exceptions are handled at the very bottom of the message loop and a generic failure message is displayed (actually, it is a tiny bit more sophisticated than that). 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);
}

UnrecoverableFailureExceptions indicate, in Design by Contract terms, postcondition failures. It says something like "Sorry, I couldn't store the name and there's nothing you can do about it.". 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...
}

What if we are in a multithreaded environment? It would be difficult (unreasonable) to guarantee that a user has not been added between checking isUserNameAdded() and calling addUser. This is a case for a checked exception.

public synchronized void addUser(String userName, UserDetails details) throws UserHasAlreadyBeenAddedException
{
// etc...
}

Consequences

• 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.

Links

• 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.

Friday, December 17, 2004 | Permalink | 1 Comments

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.

Friday, December 10, 2004 | Permalink | 0 Comments