Feature Driven Development

Peter

Interesting post!

There are a number of ways in which FDD and XP are similar, and many of these are just good practice. There are also a number of ways in which FDD and XP are fundamentally different. In part because they address different problems. You rightly identify FDD as a process, while XP is more a set of principles. This has important implications for their applicability.

You are correct in saying XP has only 2 processes (I find it hard to think of Explore as a process in its own right!). I also think the Planning Game process is mis-named and should be called Manage Requirements.

I'd like to look at how FDD and XP are similar even when apparently different, and then explore how they address different classes of problems. Finally I briefly explore what you might categorize as a theoretical difference.

BTW, I am strongly of the opinion that there is no one-size-fits-all solution to organizing software development. This is because the problems we have to solve are often very different. There are circumstances where I would use FDD and circumstances where I would use XP. It depends on the problems I have to solve and the constraints under which I have to solve them. There are also circumstances where I would use neither!

Both FDD and XP incorporate best practices established and well understood for quite a while. A good example is that FDD uses inspections to remove defects and improve quality, while XP uses pair programming. To me, they are both variants on the same thing! Pair programming is process of continuous inspections (while FDD uses discrete inspections). I am convinced both work (and this has been known for at least 20 years). The difference is which is more effective/efficient. I am not aware of empirical evidence comparing the two, but its really the only way to determine which is superior. But I stress both work and produce very similar results.

One way in which FDD and XP address different problems is in testing. XP formalizes the requirement you write the test first, whereas FDD has little to say on the subject of testing and certainly does not mandate writing the tests first. While I am a convert to automated testing, I am unconvinced of the benefits of writing tests before writing the code and I am not aware of anyone has demonstrated significant benefits.

So how do XP and FDD address different problems!

Perhaps the most important way is scale. You cannot organize a large project the same way you can organize a small one! XP works best when you have a small project (less than ten people). This is because of the interaction problem - in any system where people interact as peers, as the number of people increases linearly, then number of interactions increases logarithmically. It is well understood that any peer-to-peer system breaks down at over seven to nine people. The *only* way out of this problem is process and division of responsibilities. IMHO FDD works best with medium size projects - say ten to fifty people. I should point out that many XP proponents would dispute this. In my defence I direct you to this paper http://www.xpuniverse.com/2001/pdfs/EP205.pdf which points out that in a fifty person XP project, lack of an overall view of the system was a serious problem. Note this helps explain one way in which XP and FDD differ - in class ownership. XP says all classes are collectively owned, while FDD has class owners. I strongly suspect collective class ownership doesn't scale and the article above tends to confirm this!

A second way in which software development can vary is the extent to which the requirements are understood upfront, and have been agreed and articulated. While customers are reluctant to admit this, it is a frequent problem. There are several reasons. One is that different parts of the business have different priorities that often conflict. Another is that introducing a new system necessarily changes the problems the business needs to address (if it didnt there wouldnt be any point to the system). XP assumes that requirements are progressively exposed throughout the project and handled through progressive refactoring. In contrast FDD exposes the requirements upfront.

To summarize the XP position - You can always refactor incrementally! In effect you can incrementally increase the scope of your software indefinitely without significant issues. However, I have seen what I call the scope-discontinuity problem on a lot of software projects. It is best explained by anecdote. You have a set of requirements and design a solution (in an OO project an object model). As time passes new requirements are discovered (exposed). Your solution gracefully incorporates these new requirements, until without warning there is one requirement that your solution can not support. Your solution is broken and major refactoring is required. In contrast FDD exposes the full scope of your software upfront. This is one of the major consequencies of the first FDD process - Develop an Overall Model. The overall model defines the scope of the software upfront. This effectively avoids the scope-discontinuity problem, but at some cost in incorporating new requirements.

The third important difference between XP and FDD I'd like to highlight is the nature of the commitments they make. XP is (IMO) a variant of RAD (Rapid Application Development). RAD and therefore XP commits to deliver in specified timeframes, i.e. when, but makes no commitment on what is delivered (The Planning Game - not part of the original XP - is designed to solve this problem). Whereas FDD endeavours to define what is delivered as well as when it is delivered early in the project. This is the purpose of the startup phase (the first three FDD processes) Jeff has described in his latest newsletter.

Another way of explaining this is that there are three primary variants in software development - scope, time and resources. FDD attempts to fix all three. Process 1 - Develop an Overall Model is the first step in fixing scope. You can view it as fixing coarse-grained scope. FDD process 2 - Build a feature list, fills in the details of the scope. Process 3 - Plan by Feature attempts to fix time and resources. So by the end of the FDD startup phase, all three are fixed. In contrast XP assumes fixed resources (or makes no attempt to plan resources) and commits to frequent releases. However, the XP Planning Game is continually feeding new requirements into the development process. So scope is continually changing. A good argument can be made that the XP approach optimizes time and resources, while handling changing requirements (and priorities). The downside is that it makes the customer's planning harder because of limited visibility on future deliverables. I have a rather flippant stock answer to the question - When will the system be finished?, which is - When you run out of money! This answer contains a hard truth that is difficult for customers to grasp, that there are always more requirements for any system, irrespective of the time and resources spent to-date. There is a lot to be said for getting the customer to make the hard choices about requirements as early as possible. This is one of FDD's biggest advantages over XP!

I am an advocate of release oriented software development. There is much to recommend it. Not least the customer sees frequent tangible progress (a good way to ensure your project doesn't get cancelled ), but there are limits to the businesses capacity to implement new releases. Both XP and FDD deliver frequent new releases. I think XP is more suitable when new releases are made of an existing and in production system, especially where the business impact (i.e. the need for business changes) is small. XP also works well when developing relatively small new systems with minmal impact on existing business processes, such as some websites. I think FDD is more suitable when developing a new system of significant size, or a new software release that significantly impacts the business, because of FDD's superior visibility on deliverables and dates (for reasons explained above).

BTW, I think both XP and FDD would both be improved by a release process, but I'm straying off-topic!

Finally the theoretical difference! I would characterize this as - What is the best way to achieve the optimum underlying model for the system? While I call this a theoretical difference it has important practical consequencies!

Implicit in the FDD approach is that it is possible to create a reliable and robust domain object model from a set of relatively high-level requirements. Peter Coad and Jeff deLuca go further and say that software applications share common business domain patterns and these patterns can be re-used to produce reliable robust domain models (Implementation object models are domain models plus implementation patterns). See the Java Modelling in Color Book! I know from my own experience that robust domain models can be produced early in the development process. This has the important consequence that large scale refactoring is not required at the detailed design and development stage (assuming you got the domain model and implementation patterns right!). In contrast XP has no explicit domain model, and as previously described relies on continuous refactoring to get the right object model. Which leaves me with two key questions! How reliable is XP in getting the right object model?, and How expensive is the refactoring along the way?

As always, the opinions expressed are mine alone!

Phil Bradley