Development process

Since the XP Studio project is about supporting eXtreme Programming (XP), one would naturally assume that XP is used as the development process. Indeed, that would be our ideal. But this is also an open source project, and XP and open source development are not 100% compatible.

The main reason for this is that XP assumes a co-located team, while open source development assumes geographically dispersed developers, possibly in many different time zones.

The assumption of co-location is evident in many XP practices. Pair programming requires two developers to sit in front of one computer, sharing a single mouse and keyboard. The on site customer can only be "on site" if the development team is assembled in one location as well. Index cards can only be handled when developers are physically near to them, etc.

With a little effort, though, we can adjust the practices in such a manner that we can keep most of their advantages. In the following, we will look at each of the XP practices in turn, and see if (and how) they need to be changed in an open source development setting.

We particularly need to pay attention to how any given practice supports the other practices, since XP claims that XP works because the practices mutually support each other.

On-site customer

Open source projects usually don't have customers. They have users, of course, but those are not paying for the project, at least not in return for being able to steer the project in a direction they would like.

The XP role of Customer, i.e. the one deciding what features provide the most business value, is distributed among the many users and developers of the project. The usual solution to such a multi-headed Customer, is a technique called the Senate Game. In it, all (representatives of groups of) customers get an equal amount of votes that they can cast on the stories. The votes are counted, and the highest scoring stories are scheduled first.

However, for an open source project this solution will not work, since anyone dissatisfied with the direction the project is going in can always fork the project and change directions. Therefore, ultimately, there can be no real centralized control. This means that we will have to accept that many people will be steering the project at the same time, possibly in opposite directions.

This is not as bad as it seems, though, since most people will usually agree about which features provide the most value anyway. But it does mean that developers cannot get answers to their questions as fast (or even at all) as with normal XP.

Therefore, it becomes all the more important to document the many decisions that were taken during implementation, since they state how the system is supposed to behave, at least according to the implementer. The natural way to express these behavioral decisions, is with acceptance tests (see below).

Planning Game

As stated above, there can be no one real Customer steering the project, and therefore there can be no Planning Game in the normal sense. This is not necessarily a Bad Thing: since no one is actually paying for the project, their is no immediate need to balance value against cost.

However, each project needs to be steered somehow, or it will go nowhere. The concept of a user story is still a valuable one in this context. But, given the geographically dispersed nature of the development team, the stories must be accessible in electronic form.

Of course, the project must also be released (see also below). Since the developers are not paid, and they can always fork the project, they cannot be forced to work on particular stories first, or even at all. So, planning a release becomes harder. One usually just waits until enough stories are implemented to warrant a new release to the public.

Small releases

Since open source projects depend so much on volunteers, getting everyone to coordinate their efforts for a release can be a real challenge. The usual solution is to work with release branches in the version control system, and for someone (or a small team) to act as release manager, taking on all the chores that go with preparing the distribution(s).

As this is usually (a lot) more work than in a more traditional XP setting, the releases may be further apart in time than normal. This is not a real problem, however, because an open source project is a lot more publicly exposed than a corporate one, and users can even work with "bleeding edge" versions of the software to get their feet wet before the official release.

Remember that the principal reason for small releases has to do with feedback. And getting feedback is what open source projects excel at, with their mailing lists, forums, IRC chats, and bug tracker items.

Testing

Write programmer/unit tests before you code. This is called Test Driven Development (TDD). This is arguably the most universally applicable XP technique.

Sometimes you may feel a tendency to skip the test and delve right into the code, being sure that you know what to do. This is where your pair usually keeps you honest. Since we cannot do pair programming all the time in an open source setting (see below), we need some alternative supporting practice.

When doing TDD, every line of code you write is there to make a test pass (by definition). Therefore, it follows that running the tests should give 100% code coverage. Thus we suggest that the automated build system check this. This might seem like a stringent directive, but remember we need our tests to keep us confident when refactoring (see below). In practice, we cannot achieve exactly 100% code coverage. Things like private constructors for utility classes, and checked exceptions make this too costly. But we should be able to get close.

XP also stresses the importance of acceptance testing. Acceptance tests, or customer tests, show that the system works in a format that is understandable by the customer, e.g. tables in FIT.

Of course we also need acceptance tests in an open source development setting. They will show potential users that the system works. However, we cannot have the build system enforce them in the same way as we can have it enforce unit tests. The main reason for this, is that acceptance tests usually do not cover all the error cases, as unit tests do. We could, of course, aim for something less than 100% coverage, but the exact number to use would be variable across projects and maybe even across subsystems within a single project. Nevertheless, aiming for, say, 60% coverage by acceptance tests would be nice, as long as a warning is given, not a complete build failure.

Refactoring

Improve the design of the application without changing the external behavior.

As with TDD, you sometimes are tempted to skip it and get on with the "real" job: coding. Again, we can use the build system to keep you on track. It can perform some static analysis of the code to look for smells, much as your pair would.

Sustainable pace/ No overtime

It is not uncommon for open source projects to see people contribute in fits and bursts. Developers make up their own mind about whether they want to donate their spare time to the project. Since they do not work office hours, they technically cannot work overtime.

However, they might want to try to accomplish more in the few hours they can spare than is healthy for them. As within corporate environments, this will show in their code. In that case, the very openness of the project will usually mean that someone criticizes the resulting poor design in the mailing list, or that someone else will perform the refactoring needed. Thus it seems we need no extra provisions here.

Pair programming

The usual form of pair programming, with two people sitting in front of a single computer, sharing mouse and keyboard, is something that is not easily attainable in open source projects. Since this is such an important practice, that acts as support for many other practices, it pays to have a good look at some of the alternatives.

Some people have suggested Distributed Pair Programming (DPP). This certainly looks promising, and we want to support it with XP Studio. But with people volunteering their time as they see fit, and with people potentially in time zones that are far apart, it becomes clear that DPP can only go so far.

We already looked at the build system as a virtual pair, albeit a limited one. Still, something is more than nothing, and any help is welcome.

A third alternative is design up front. Not BIG design up front (shrug), of course, but nevertheless. This is pretty common for open source projects, where designs are regularly discussed on the mailing lists.

Simple design

We need code that passes all the tests, expresses intentions clearly, and has the fewest number of classes and methods (in that order), as expressed in the mantra: make it run, make it right, make it fast.

The peer pressure in open source projects is usually enough to keep the design simple. However, very specialized areas of the code may receive less attention from scrutinizing eyes than the more general ones. So, in the absence of a pairing partner (see above), it is helpful to have the build system check some simple design metrics.

Coding standards

Coding standards are the norm in open source projects. We can even have the build system enforce them.

Continuous integration

Again, this is the norm in open source settings. Usually this is formalized with a continuous integration server like CruiseControl, that automatically runs all the tests after a commit, and notifies committers after failures.

Collective ownership

This is what open source is all about. Yet, most projects do not grant full commit access to all developers: so called partial committers are only allowed to make changes in their area of expertise. Still, anybody can make changes in any area and submit them as a patch.

Metaphor

Having a metaphor is just as useful in open source projects as it is in corporate settings. Maybe even more, since many developers will be working on and off on the project. With a clear vision of what the system is all about, they are less likely to make silly mistakes based on misconceptions.