I recently upgraded Ubuntu to its latest version (9.10, Karmic Koala) and it works great so far. Except for Eclipse.

I ran Eclipse 3.5 (Galileo), and apparently SWT in that version does something wrong in communicating with GTK. The end result is that buttons don’t react to mouse clicks anymore. Rather annoying. Luckily, there is a solution available. Alternatively, you can use the latest Eclipse 3.6 (Helios) milestone.

But that wasn’t the end of it. Eclipse would now perform extremely slowly on a variety of tasks. It turns out that this is caused by Eclipse now running on the GCJ Virtual Machine. I simply uninstalled everything with “gcj” in its name using Synaptic and all was well again.

Finally, the time has come: JavaFX is now supported on both GNU/Linux and Solaris.

It’s not really advertised, though, so h Here’s how to get it:

• Go to the JavaFX website.
• Click the Download now button. Yes, the one that reads JavaFX 1.1 SDK.
• Click the JavaFX 1.1.1 1.2 SDK option, and click Download.
• You’ll be prompted to download javafx_sdk-1_2-linux-i586.sh. Save it somewhere convenient.
• Make the downloaded file executable with chmod + x
• Run the shell script with ./javafx_sdk-1_2-linux-i586.sh
• Page through the annoying legal stuff by pressing Space repeatedly. At the end, type yes.
• You now have a javafx-sdk1.2 directory that you can play with.

Enjoy!

Oh, and in case you have some JavaFX code from pre-1.2 versions, here’s how to migrate it.

Update: There is also a new Eclipse plugin. Binaries only, the source will have to wait until it gets transferred to eclipse.org.

As an application evolves, its data model often does too. If you control both, this usually isn’t a problem. However, sometimes your power to change the data model is restricted. This happens, for instance, when the data model is published, and others may depend on it. An extreme case of this is when the data model is defined by another organization as, for example, with S1000D.

Having no absolute control over the data model isn’t much of a problem if you can leave one version behind completely, and move on to the next. But often you won’t be so lucky. I know I’m not: we need to support both S1000D 3.0 and 4.0.

There’s different ways in which you can support multiple data model versions. The one I’m concerned with here, is when your application needs to support multiple data models at the same time with the same code. That leaves out alternatives like having multiple branches of your code for the different data model versions.

One trick that can come to the rescue here is the Once And Only Once rule (also called the DRY principle). When applied to creating instances, this leads to the Factory pattern. If you have all your instances created by a factory, then there’s only one place where you need to decide which class (e.g. the 3.0 or 4.0 version) to instantiate. If those decisions are similar for all the classes in your model, then you could even extract them into a common base class for your factories.

Most of the time, the different versions of the data model will share a lot of similarities. It is tempting to extract those into a common base class. For example, in S1000D there is a type called descriptive data module, and you could derive DescriptiveDataModule30 and DescriptiveDataModule40 from DecriptiveDataModule.

But when the objects in your data model have inheritance relationships themselves, that can get ugly very fast. For instance, a descriptive data module is one of many kinds of data modules, and these data modules share a lot of characteristics. So in code, DescriptiveDataModule would descend from DataModule, and both would have aspects that differ in the 3.0 and 4.0 versions. This spells trouble.

Therefore, it is usually better to use composition instead. So DataModule would have a reference to a DataModuleIssue (where “issue” is used in the sense of the various issues of the S1000D specification, i.e. what I’ve been calling “versions” so far), which the DescriptiveDataModule would inherit. The factory would inject either a DescriptiveDataModuleIssue30 or a DescriptiveDataModuleIssue40 into the DescriptiveDataModule, where DescriptiveDataModuleIssue30 would descend from DataModuleIssue30, and DescriptiveDataModuleIssue40 from DataModuleIssue40.

The idea is to make the Issue classes very bare, dealing only with the stuff that differs between issues, so there is no need for a common base class (although both do implement the same interface). The things that are the same in all issues, go into the core model objects (DescriptiveDataModule and DataModule in our example).

Lately, I’ve seen a lot of discussions on Kanban. For those of you who, like me, want to know what all that fuss is about, I collected a couple of links that I will try to merge into a coherent whole below.

So what exactly is Kanban? Literally, it means “visual card”, but that’s not very helpful. This introduction explains that Kanban revolves around a board that visualizes the software development flow.

In fact, flow is a very important concept here. Kanban is a pull system, in which Minimal Marketable Features (MMFs) flow through the development stages when there is capacity available. This contrasts with most Agile methods that push work items into iterations. Also, note that for most Agile methods, those work items (e.g. User Stories) would be smaller than MMFs.

The other big point is that Kanban limits Work In Progress (i.e. the number of MMFs per development stage). This naturally exposes the bottleneck(s) in the flow.

This leads us nicely to the main reason to use Kanban: to improve your software development process. Other Agile methods deal with process improvement as well, but Kanban is different from e.g. Scrum.

So, if all this sounds cool and you want to give Kanban a shot, then apparently this is how you should get started. If you do, then you may see these effects. Also, make sure to get into a Kanban state of mind.

Update: here is a great compilation of Kanban resources.

Elisabeth Hendrickson wants to get rid of the word “test”, as it can mean two different things, which she labels “Check” and “Explore”.

I very much agree with the fact that there are two entirely different aspects to testing. “Checking” is when you get a warm fuzzy feeling when the bar gets green. You perform an experiment and if you get a positive result then you know that all is well.

“Exploring” is different in that you don’t get a warm fuzzy feeling on “green”. In other words, if the experiment produces a positive result, you’re not done yet. You need to look further, until you find a negative result. Only then will you have learned something. And if you spend some time exploring, and find no problems, then there’s always that nagging feeling: is there really nothing to find, or did I just not look hard enough?

So it seems I agree with Elisabeth. Then why this blog post?

Like Elisabeth, I think that words matter. She’s right to want to replace the word “test”. I just disagree with the replacements. “Check” has way too many meanings, and the definitions of “explore” don’t seem to catch what is meant well enough for my taste.

So I’d like to propose an alternative from the world of science: “verify” and “falsify”. Automated tests verify that the software behaves as expected, while exploratory testing falsifies both the expectations and the completeness of the test suite.

What do you think?

OSGi is gaining a lot of traction lately. But what if you have a very large application? Migration can be a lot of work.

I would like to point to a simple tool we use that might help out a bit here. It’s called Macker and

it’s meant to model the architectural ideals programmers always dream up for their projects, and then break — it helps keep code clean and consistent.

Macker is open source (GPL). It’s current version is 0.4 and has been for a long time. That doesn’t mean it’s immature or abandoned, however. It’s author had a lot more features planned, hence the 0.4. But what’s already available is enough to give it a serious look.

So, what does Macker do, exactly? It enforces rules about your architecture. For example, suppose you have a product with a public API. You could create a rule file with an <access-rule> that the API must be self-contained:

  <message>The API should be self-contained</message>
  <deny>
    <from pattern="api" />
  </deny>
  <allow>
    <from pattern="api" />
    <to pattern="api" />
  </allow>
  <allow>
   <from pattern="api" />
    <to pattern="jre" />
  </allow>

These rules can be very explicit about what is and what isn’t allowed. There are several ways to specify them, but I’ve found it easiest to use patterns, like in the example above, since they can have symbolic names. Here’s an example:

<pattern name="api">
  <include class="com.acme.api.**"/>
</pattern>

Where the ** denotes every class in the com.acme.api package, or any of its sub-packages. See the Macker user guide for more information about supported regular expressions.

Macker comes with an Ant task, so you can enforce your architecture from your build. Maybe not as good as OSGi, but it sure helps with keeping your code the way you intended it.

So you’re developing this cool Java application where you access XML data using XQuery. Easy enough with a powerful XML database like xDB, right? Well, yes and no This document addresses some of the issues you may encounter.

The naive approach

The easiest way to execute XQuery statements, is to embed them into your Java code:

executeXQuery("for $a in document('/content/repository)"
    + " where $a//html/head/title = 'Using XQuery'"
    + " return $a");

where executeXQuery() executes the XQuery against your XML database.

Most of your XQuery statements won’t be static like this example. Rather, you’d get some input from your end user:

    final String title = getInputFromEndUser();
    final String xquery
        = "for $a in document('/content/repository)"
        + " where $a//html/head/title = '"
        + title
        + "' return $a";
    executeQuery(xquery);

Problems with the naive approach

This approach has some problems, though. First of all, the last XQuery is vulnerable to an XQuery Injection attack. This is the same as a SQL Injection attack, but based on XQuery instead of SQL. Like with SQL programming, you can use variables to work around this issue:

final String title = getInputFromEndUser();
final String xquery
    = "declare variable $title external;"
    + "for $a in document('/content/repository)"
    + " where $a//html/head/title = $title"
    + " return $a";
executeQuery(xquery, title);

where executeXQuery() now accepts a variable number of arguments after the XQuery statement that are values for the externally declared variables.

But there are still some maintainability issues with this code. For starters, see the argument to the document() function. This depends on the particular database layout for your application. If you’ll ever need to change it, you’ll likely need to update hundreds of XQuery statements. You could, of course, extract this into a constant.

But there is more. Your XQueries are likely to go beyond the basic XQuery specification, for instance to search on meta-data. In xDB, that would read something like this:

final String title = getInputFromEndUser();
final String xquery
    = "declare variable $title external;"
    + "for $a in document('/content/repository)"
    + " where xhive:metadata($a, 'Title') = $title"
    + " return $a";
executeQuery(xquery, title);

You’ve now added a dependency on a specific implementation, which is never a good idea, since it basically generates a self-inflicted vendor lock-in.

Of course, you could extract the vendor-specific parts as well, but by now I hope you begin to see the mess you’ll end up with.

Worse, since you embed the XQuery statement as a String in your Java code, any typos you make in this unreadable statement can only be found at runtime, since the Java compiler doesn’t understand XQuery.

XQuery Builder to the rescue

Let’s take a step back here and look at what we’re trying to achieve. We want to construct an object (an XQuery statement), that we want to use later on (execute it against our XML database). This is a recurring pattern, called the Builder Pattern. So we need an XQuery Builder.

Now, the XQuery standard is complex enough that I don’t recommend spending a lot of time coming up with the perfect XQuery Builder. Instead, you should take it slow, and only implement what you really need.

The best way to do that is using Test-Driven Development (TDD). I like to think that’s always the case, but even if you disagree, there are good reasons why it is the best approach in this scenario.

You’ll evolve the XQuery Builder over time, adding capabilities as needed, so you need a good suite of unit tests to ensure you didn’t break anything. Also, TDD focuses first and foremost on the API that you want to realize, making it easier to come up with a clean design.

Speaking of a clean design, the Builder Pattern lends itself very much to the use of a fluent interface, since you want to be able to express the XQuery in code as much as possible as you would in a string. Here’s an example of the sort of thing we’re trying to achieve:

    final String xquery = builder
        .where().metaData("Title").isEqualTo(title)
        .and().uri().startsWith(prefix)
        .orderBy().uri()
        .returns().id()
        .build();

Let’s take a look at how the XQuery Builder approach solves the problems we identified earlier.

First the security issue. The example above doesn’t explicitly mention external variables, but that doesn’t mean that they aren’t used. If your code needs security, the XQuery Builder can provide it. If you’re absolutely sure that your application only runs in a trusted environment, you can leave it out. If you later discover that your environment isn’t as secure as you thought, you can add support for external variables in the XQuery Builder and be done with it. No need to change hundreds of XQuery statements!

Next, notice that the example didn’t mention where to look for documents. The XQuery Builder is the only place where the repository layout is specified, so that it is easy to update.

There is also nothing vendor specific in the example above. The metaData() clause handles that, again in one place.

Arguably the biggest benefit of the XQuery Builder, however, is that it gives you (some) compile time checking of your XQuery statements. For example, if you were to write builder.hwere(), the Java compiler would tell you about it right away.

You can take this as far as you think is useful. For instance, notice the uri() method in the example. Apparently, this application uses URIs on objects a lot, so it made sense to make it easy to use them. The same apparently didn’t hold for the Title meta-data field. By developing your own XQuery Builder, you get to decide the API that makes sense for your application.

Creating an XQuery Builder

So, how hard is it to create such an XQuery Builder? That depends on how far you want to go. But the beginnings are simple.

Start out with this JUnit 4 test:

import static org.junit.Assert.assertEquals;

import org.junit.Before;
import org.junit.Test;

public class XQueryBuilderTest {

  private XQueryBuilder builder;

  @Before
  public void init() {
    builder = new XQueryBuilder();
  }

  @Test
  public void all() {
    assertEquals("XQuery",
        "for $a in document('/content/repository')\n"
            + "return $a",
        builder.build());
  }

}

which forces us to write this code to make it compile:

public class XQueryBuilder {

  public String build() {
    return null;
  }

}

The test obviously fails. For now just fake it by returning "for $a in document('/content/repository')\nreturn $a".

This first step may seem a bit silly to those not used to TDD, but it is essentially just a way to get set up. In TDD, you don’t want to write code without a failing test, so always try to get a failing test as fast as possible.

Now, for something a bit more interesting. Let’s test that the XQuery can return IDs of documents, since we’ll need that very often:

@Test
public void returnId() {
  assertEquals("XQuery",
      "for $a in document('/content/repository')\n"
          + "return xhive:metadata($a,'id')",
      builder.returns().id().build());
}

In fact, that’s a special case of returning some meta-data, so we’ll tackle the simpler case first:

@Test
public void returnMetaData() {
  assertEquals("XQuery",
      "for $a in document('/content/repository')\n"
          + "return xhive:metadata($a,'foo')",
      builder.returns().metaData("foo").build());
}

For this to compile, we need a returns() method in XQueryBuilder:

public class XQueryBuilder {

  private final Return returns = new Return(this);

  public String build() {
    final StringBuilder result = new StringBuilder();
    result.append(
        "for $a in document('/content/repository')\n");
    result.append(returns);
    return result.toString();
  }

  public Return returns() {
    return returns;
  }

}

Note that we can’t use the more natural term return, since that is a reserved word in Java. Here’s the Return class:

public class Return {

  private final XQueryBuilder builder;
  private MetaDataReturnClause clause;

  public Return(final XQueryBuilder builder) {
    this.builder = builder;
  }

  public Return metaData(final String name) {
    return setClause(new MetaDataReturnClause(name));
  }

  private Return setClause(
      final MetaDataReturnClause clause) {
    this.clause = clause;
    return this;
  }

  @Override
  public String toString() {
    final StringBuilder result = new StringBuilder(
        "return ");
    if (clause == null) {
      result.append("$a");
    } else {
      result.append(clause);
    }
    return result.toString();
  }

  public String build() {
    return builder.build();
  }

}

And here’s the MetaDataReturnClause:

public class MetaDataReturnClause {

  private final String name;

  public MetaDataReturnClause(final String name) {
    this.name = name;
  }

  @Override
  public String toString() {
    return "xhive:metadata($a,'" + name + "')";
  }

}

So implementing the ID is easy:

public class Return {

  public Return id() {
    return setClause(new IdReturnClause());
  }

  // ...
}

public class IdReturnClause
    extends MetaDataReturnClause {

  public IdReturnClause() {
    super("id");
  }

}

By now you probably spotted some duplication. First the tests:

  @Test
  public void all() {
    assertXQuery("return $a", builder.build());
  }

  @Test
  public void returnMetaData() {
    assertXQuery("return xhive:metadata($a,'foo')",
        builder.returns().metaData("foo").build());
  }

  @Test
  public void returnId() {
    assertXQuery("return xhive:metadata($a,'id')",
        builder.returns().id().build());
  }

  private void assertXQuery(final String expected,
      final String actual) {
    assertEquals("XQuery",
        "for $a in document('/content/repository')\n"
        + expected, actual);
  }

Yes, it’s just as important to keep your tests clean as it is for your code! Speaking of which, there are a lot of places where this $a thingie comes up. Let’s extract it:

public class XQueryBuilder {

  public String build() {
    final StringBuilder result = new StringBuilder();
    result.append("for ").append(getContext())
       .append(" in document('/content/repository')\n");
    result.append(returns);
    return result.toString();
  }

  public String getContext() {
    return "$a";
  }

  // ...
}

So that the Return class can use it:

public class Return {

  private final XQueryBuilder builder;
  private MetaDataReturnClause clause;

  public Return(final XQueryBuilder builder) {
    this.builder = builder;
  }

  public Return metaData(final String name) {
    return setClause(new MetaDataReturnClause(this,
        name));
  }

  public Return id() {
    return setClause(new IdReturnClause(this));
  }

  private Return setClause(
      final MetaDataReturnClause clause) {
    this.clause = clause;
    return this;
  }

  @Override
  public String toString() {
    final StringBuilder result = new StringBuilder();
    result.append("return ");
    if (clause == null) {
      result.append(builder.getContext());
    } else {
      result.append(clause);
    }
    return result.toString();
  }

  public String build() {
    return builder.build();
  }

  public XQueryBuilder getBuilder() {
    return builder;
  }

}

And the MetaDataReturnClause as well:

public class MetaDataReturnClause {

  private final String name;
  private final Return returns;
  private XQueryBuilder builder;

  public MetaDataReturnClause(final Return returns,
      final String name) {
    this.returns = returns;
    this.name = name;
  }

  @Override
  public String toString() {
    return "xhive:metadata("
        + returns.getBuilder().getContext()
        + ",'" + name + "')";
  }

}

You can probably see the getContext() method gaining traction when considering recursive XQueries. As always, keeping your design clean makes it easier to enhance later.

So there you have your basic XQuery Builder. From these humble beginnings, it’s easy to add more functionality. For example, suppose we want to return not just the ID, but also the URI of an object. First we add support for URIs in the return clause, since we anticipate we’ll it need often:

  @Test
  public void returnUri() {
    assertXQuery("return xhive:metadata($a,'uri')",
        builder.returns().uri().build());
  }

Which is implemented along the same lines as before:

public class Return {

  public Return uri() {
    return setClause(new UriReturnClause(this));
  }

  // ...

}

With a new class UriReturnClause:

public class UriReturnClause
    extends MetaDataReturnClause {

  public UriReturnClause(final Return returns) {
    super(returns, "uri");
  }

}

Next, we need to be able to return multiple items:

  @Test
  public void returnIdAndUri() {
    assertXQuery("return (xhive:metadata($a,'id'), "
        + "xhive:metadata($a,'uri'))",
        builder.returns().id().and().uri().build());
  }

The and() method is just syntactic sugar to make the code easy to read:

  public Return and() {
    return this;
  }

To pass the test, we need to change the clause instance variable to a list:

public class Return {

  private final List clauses = new ArrayList();

  public Return metaData(final String name) {
    return addClause(new MetaDataReturnClause(this,
        name));
  }

  private Return addClause(
      final MetaDataReturnClause clause) {
    clauses.add(clause);
    return this;
  }

  @Override
  public String toString() {
    final StringBuilder result = new StringBuilder();
    result.append("return ");
    if (clauses.isEmpty()) {
      result.append(builder.getContext());
    } else {
      if (clauses.size() > 1) {
        result.append('(');
      }
      String prefix = "";
      for (final MetaDataReturnClause clause : clauses) {
        result.append(prefix).append(clause);
        prefix = ", ";
      }
      if (clauses.size() > 1) {
        result.append(')');
      }
    }
    return result.toString();
  }

  // ...

}

Adding support for the where and orderBy clauses follows the same approach as for return and is left as an exercise for the reader

In doing so, you will probably encounter some duplication for e.g. meta-data handling between the where, orderBy and return clauses, which you can extract into e.g. XQueryBuilder.getMetaDataClause().

Have fun writing your XQueryBuilder based Java applications!

eXtreme Programming Markup Language (XPML) uses several XML documents that are interrelated. For example, releases refer to iterations, which refer to user stories, which might refer to use cases. These objects are referenced by name in the XML documents, and any code that deals with them needs to translate these names into real object references.

This is the situation that the Registry Pattern describes:

Objects need to contact another object, knowing only the object’s name or the name of the service it provides, but not how to contact it. Provide a service that takes the name of an object, service or role and returns a remote proxy that encapsulates the knowledge of how to contact the named object.

It’s the same basic publish/find model that forms the basis of a Service Oriented Architecture (SOA) and for the services layer in OSGi.

In XP Studio, the named objects of interest are the planning objects, e.g. releases, iterations, and such:

public interface PlanningObject {

  /**
   * @return The object's name
   */
  String getName();

  /**
   * Set the object's name.
   * @param name The name to set
   */
  void setName(String name);

  // ...
}

Any code that needs to reference such a planning object, can use the registry:

public class Registry {

  private static Registry instance;

  private final Map registry = new HashMap();

  public static synchronized Registry getInstance() {
    if (instance == null) {
      instance = new Registry();
    }
    return instance;
  }

  public synchronized Reference getReference(
      final String name) {
    final Reference result;
    if (isRegistered(name)) {
      result = registry.get(name);
    } else {
      result = new Reference(name);
      registry.put(name, result);
    }
    return result;
  }

  private boolean isRegistered(final String name) {
    return registry.containsKey(name);
  }

  public synchronized void register(
      final PlanningObject object) {
    final Reference reference = getReference(
        object.getName());
    if (!reference.hasObject()
        || reference.getObject() != object) {
      reference.setObject(object);
    }
  }

  public synchronized void unregister(
      final PlanningObject object) {
    if (isRegistered(object.getName())) {
      final Reference reference = getReference(
          object.getName());
      if (reference.hasObject()) {
        reference.setObject(null);
      }
    }
  }

}

Note that the actual code uses Java5 generics, but WordPress’ source code formatter can’t handle that.

The planning objects use the registry to register themselves:

public class PlanningObjectImpl
    implements PlanningObject {

  private String name = "";

  public PlanningObjectImpl(final String name) {
    setName(name);
  }

  public String getName() {
    return name;
  }

  public final void setName(final String name) {
    if (!this.name.equals(name)) {
      Registry.getInstance().unregister(this);
      this.name = name;
      Registry.getInstance().register(this);
    }
  }

  // ...
}

Now any client code can get references to the planning objects:

public class Reference {

  private PlanningObject object;
  private final String name;

  public Reference(final String name) {
    this.name = name;
  }

  public String getName() {
    return name;
  }

  public boolean hasObject() {
    return object != null;
  }

  public PlanningObject getObject() {
    return object;
  }

  public void setObject(final PlanningObject object) {
    this.object = object;
  }

}

One example of using references is with user stories, which may depend on other user stories:

public class UserStoryImpl extends PlanningObjectImpl
    implements UserStory {

  private final Set dependsOn = new HashSet();

  public UserStoryImpl(final String name) {
    super(name);
  }

  public void addDependsOn(final String userStoryName) {
    dependsOn.add(Registry.getInstance().getReference(
        userStoryName));
  }

  public Set getDependsOn() {
    final Set result = new HashSet();
    for (final Reference reference : dependsOn) {
      if (reference.hasObject()) {
        result.add((UserStory) reference.getObject());
      }
    }
    return result;
  }

  // ...

}

That’s the basic registry pattern implementation.

The actual code in XP Studio employs some enhancements. One of them is the use of namespaces so that objects in different projects can use the same name.

Another neat trick is to override the equals() method of both PlanningObjectImpl and Reference to make sure that references and the objects they refer to are regarded as the same, which can greatly simplify some code.

Pair programming (PP) is one of the eXtreme Programming (XP) practices. When doing pair programming, two programmers share a mouse and keyboard while they write code. One of the two, the driver, types, while the other, the navigator, reviews the code, and thinks ahead. The two persons switch roles often. This is another example of XP ‘turning the knobs to 10′: if reviewing code is good, then we should do it all the time.

There is a good post on PP by Rod Hilton. He starts out with

When I first heard I’d be pairing at the new job, I was a bit apprehensive and skeptical.

I can relate to that. At a former company I worked for, I introduced XP. I had just read XP Explained: Embrace Change and thought it could improve our software development process. But pair programming was the one practice I was apprehensive about. The thought of someone watching over your shoulder all day made me feel uneasy. Yet the book made it clear that PP is a foundational practice, so I tried to keep an open mind.

I shouldn’t have worried. Rod explains that PP has nothing to do with “looking over a shoulder”:

The way pair programming works in practice is quite a bit different than I imagined it. [...] When doing Test-Driven Development, one of the things we do is called “ping-pong pairing”. So the other developer will write a test, then make it compile but fail. Then he passes the keyboard to me. I implement the feature just enough to make the test pass, then I write another failing test and pass it back.

I didn’t know about ping-pong pairing when we started out doing XP. In fact, Rod’s post introduced it to me. It seems like a really good technique, and I’d love to try it out.

Also, the “all day” part is a misconception:

In reality, you don’t sit down at a desk with another person and work all day with them. You pair up for tasks. [...] When the task is done and code is checked in, the pair breaks up. Generally tasks only have 2 hour estimates (sometimes less) so you’re only pairing for the two hours. Then you pair up with someone else to work on another task. [...] We take breaks often because getting away from the code for a few minutes helps keep a fresh perspective when you come back to the task.

When I did XP, we paired up for about three hours at a time. We all came in on different times, so PP time generally started at about 9:30 AM, and lasted till lunch. Then we’d switch pairs. Since some of us started early, they also left early (Sustainable Pace), so there was another session of about three hours in the afternoon.

Pairing for about six hours a day is really enough. PP is pretty intense! There is no chance to let your mind wander off a bit, to look out of the window for more than a couple of seconds or to read e-mail. You have to stay focused all the time.

Advantages

So why bother at all with PP? Rod explains:

I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time. [...] When you have a second person working with you, you find that you try harder to code well. You’re far, far less likely to be willing to apply duct tape to a problem, because someone else is working with you and he or she is more likely to object to the duct tape.

We all know the feeling, I guess. You know that you’re taking a shortcut, that there is a better way. But that would take more effort. When you’re pairing, your partner “keeps you honest”. You don’t want to look like a slouch, so you don’t even consider the shortcut.

This makes a big difference. In fact, while I consider myself a pretty good programmer, I must admit that the code I wrote when pairing was of considerable higher quality than the code written solo. And that is true even when pairing with someone that I knew for sure was a lesser programmer than me!

The “keeping you honest” thingie is one reason for this. “Two brains think of more than one” is another. The interplay between the driver and navigator is a subtle one. When you, as a driver, see the navigator’s eyes go blank, you know you’re code is not as clear as it could be. And you fix it. You either stop to explain, at which point the navigator will likely suggest an improvement (like a better name for a class to better express its purpose), or you switch roles and let the navigator write better code.

Disadvantages

So why isn’t everybody pairing? What’s the catch?

Well, there are downsides. Rod mentions one:

Hygiene can be a serious problem. If one person smells, it’s rough to sit with them. I find myself going back to my desk often and the code suffers for it. If you’re pairing, take a shower, and hold your farts for your next bathroom trip. Just do it, you filthy pig.

I haven’t dealt with this problem much. One guy I paired with was a smoker, so whenever he came back from a smoke outside, I’d smell the smoke. I didn’t like it, but so what. We all have our faults. Pair programming is a partnership, and like in any partnership, you need to give and take a bit PP takes some time to get good at, but the basics skills should have been acquired at Kindergarten.

Rod also mentions productivity:

there’s no denying that you’re producing fewer lines of code per day since only half your team is coding at any one point. I don’t consider that a bad thing, though (if you have two solutions that equally solve a problem, the solution with fewer lines of code is the superior one) because the QUALITY of the code that IS produced is so, so, so much higher.

This is an important point to stress. Pair programming seems wasteful, but it’s really not. The limiting factor when programming is not the speed with which you type, but the number of bugs you don’t introduce. There hasn’t been much scientific research into this, but there is one nice experiment by Alistair Cockburn and Laurie Williams that finds that PP takes 15% more time, but produces 15% less bugs, while yielding a significantly simpler design. My experiences confirm this.

The long term benefits of these advantages cannot be overestimated. Each bug takes away future coding time, since it needs to be fixed. And more complex designs slow you down as well, because it requires more time to understand the code you’re working on, and increases the chances of introducing bugs because of misunderstandings.

Of course, there will always be nay-sayers. Most of them haven’t actually tried PP, because “that could never work”. Well, if you don’t want to learn, then don’t, but don’t bother me. If you did give PP a try and failed to get good results, I must press you to check whether you did PP properly. If you think you did and still didn’t like PP, then please leave a comment explaining why.

If you’re an agile team wanting to build better software, then check out abetterteam, “Because it takes an awesome team to build awesome software“.

Ron Jeffries, one of the three founders of eXtreme Programming, and one of original signatories of the Agile Manifesto states:

We must evolve the infrastructure. It’s not a rule, it’s worse. It’s essentially a law of nature.

Please read his whole excellent post to understand why. And then, if you haven’t already, read Martin Fowler’s book Refactoring and start applying it.

Only today I found out the sad, sad news that one of my favorite bands, After Forever, decided to quit.

At my organization, we use a lot of the tricks from the Agile toolbox, like unit tests (although most of us are not doing TDD), refactoring, continuous integration, collective code ownership. We also write black box tests using Selenium and HtmlUnit, but since the developers think them up and implement them, not the customers, we can’t really call them acceptance tests.

If you look at this list, you probably notice that these are all technical practices. What has been lacking so far are the more management oriented ones. But my team has now embarked on a journey to incorporate some of those.

We’re using user stories to define functionality, and deliver them in iterations. Since we’re building a product, not doing a project, our product manager plays the customer role.

The planning game wasn’t easy, since it was all so new for us. But the first iteration delivered all planned stories, the first ever deadline that the team made! Although it is far too early to declare victory, the start is promising indeed.

We do face some challenges, however. Our customer is in Kentucky, USA, while the development team is in The Netherlands. Also, I work from home about half of the time. So we’re definitely not a co-located team. This means we have to invest more in communication. We use e-mail, instant messaging and conference calls to stay in touch.

The distributed nature of our team makes capturing user stories on index cards difficult. Since we’re pretty XML focused (our department is the R&D department for XML in our company), we decided to capture the stories in XML instead and store them in our source source repository.

I know that many in the Agile community don’t like this formalization (Individuals and interactions over processes and tools), but it does have advantages. The biggest one in my book, after making distributed development possible, is that it opens up a whole lot of possibilities for automation. Remember Ubiquitous Automation?

This was the stimulus I needed to breathe some new life in one of those open source projects I participated in, but neglected lately: XP Studio. Check it out and let me know what you think.

We had some fun today with planning poker. Wikipedia defines it as

… a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development. It is a variation of the Wideband Delphi method. It is most commonly used in agile software development, in particular the Extreme Programming methodology.

Our process was a little different than standard: we worked on defining the stories on our Wiki in the days leading up to the planning poker game, so that we didn’t have many discussions prior to estimating each feature. But we did have some very good discussions when we saw big deviations in people’s estimates.

Sometimes people assumed that stuff was included in the story that was actually in a different story, leading to much higher estimates. Sometimes people forgot about tasks, leading to lower estimates. But as a team, we think we have come up with some good estimates. We will see how they hold up in real life

To actually play the planning poker game, you’d normally need a deck of cards with values. However, being a distributed team today (I worked from home), we resorted to planningpoker.com. It’s really simple to use and actually fun. Our discussions took place in IM, and although that’s not optimal, it was good enough. So all in all a good experience.

Update: You can also use this site to reach consensus on a story’s risk. For that, agree on a mapping between the planning poker cards and the allowed values for risk. For instance, if you assign risk a value of low, medium, or high, you could pick 0=low, 5=medium, 100=high.

A while ago I wrote about how the JavaFX Eclipse plugin has some shortcomings. Luckily, the plugin is released under an Open Source license (BSD). Therefore, the source is available, and anyone can fix problems and supply patches.

So I decided to do just that, and checked out the code from the Subversion repository. I followed the steps described in the Wiki to get the project compiled.

The first thing I ran into, is that the default target didn’t exist. That was easy enough to fix.

Next, it bothered me that I needed to provide several properties on the command line. For instance I needed to specify -DeclipseDir=/opt/eclipse every time. So I patched the build to get this location from the environment variable ECLIPSE_HOME which I set in my .profile.

The same goes for the location of the JavaFX SDK. I introduced a JAVAFX_HOME environment variable to store that location. With these three modifications I could finally issue a build with just a simple ant.

With the build working it was time to tackle one of the problems I encountered during my usage of the plug-in. I figured it would be easy to fix the issue where compilation errors use up three lines in the Problems view, so that’s where I started. Based on information in the book Eclipse, Building Commercial-Quality Plug-ins, I knew I had to look for IMarker. There was only one such place in the code, so the problem was easily fixed. Progress at last!

I took a look at the other issues that were reported against the plug-in. There might be easier ones than the ones I experienced Indeed, someone noticed that the JavaFX perspective missed an icon. At first I couldn’t reproduce it, but that was because I was starting the plug-in from Eclipse. The official distribution did show the problem. Luckily, the bug reporter also found the cause: the icon used wasn’t part of the jar. A simple addition to build.properties fixed that.

Five patches already! I was feeling pretty good about myself

Next, someone wanted help with import statements. That was a lot trickier, but probably also a lot more valuable. Having looked at the IMarker code before, I naturally wanted to add a marker resolution.

This turned out to be a lot more work than I anticipated, but I managed to get something working. There were some glitches, and it probably needed a lot more testing for corner cases, but I could add a missing import statement based on the class name. Because I felt that this code wasn’t ready for prime time yet, I didn’t supply a patch, though.

This patching frenzy took place during the holidays. I got no response from Sun during that time, but I guess that was to be expected, given the time of year. So I decided to wait until some time into the new year to see what would happen.

Monday January 5 went by without news, but this morning I started to receive a stream of email notifications about issue tracker updates. Several of my patches were being accepted, and then I even received notification that I was given commit access! Such are the wonders of Open Source…