- Introduction
- FDD Summary
- Short Comparison with XP
- Bottom Line
- References
- Acknowledgments
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Short Comparison with XP
Reading the introductions to FDD and XP reveals many similar factors driving the development of the two processes:
Traditional heavy processes with long "analysis phases" are unworkable for projects running on Internet time; business requirements are changing monthly if not weekly.
Software continues to be delivered late and over budget with less useful functionality than first envisioned.
Both FDD and XP are designed to enable teams to deliver results faster without compromising quality. Both processes are highly iterative and results-oriented. They're both people-focused instead of document-focused (no more thousand-page specifications to write). Both dismantle the traditional separation of domain and business experts/analysts from designers and implementers; analysts are dragged out of their abstractions and put in the same room as developers and users. These new processes, together with new tools and techniques, are enabling and encouraging analysis, design, code, test, and deployment to be done concurrently.
So where do FDD and XP differ?
Team Sizes
"XP is designed to work with projects that can be built by teams of two to ten programmers, that aren't sharply constrained by the existing computing environment, and where a reasonable job of executing tests can be done in a fraction of a day." [Beck]
FDD was first used with a team of 16–20 developers of varying abilities, cultural backgrounds, and experience: four chief programmers (CPs), sixteen class owners split into user interaction (UI), problem domain (PD), and data management (DM) teams. FDD is designed to scale to much larger team sizes. The limiting factor is the number of available CPs. Chief programmer teams have been proven in practice to scale well to much larger project teams (by the authors of FDD and independently [Brooks]).
Metaphor and Model
The XP process begins with the business writing stories on index cards. A story is something that the system needs to do. Development then estimates the time required to implement each story. The whole project is guided by a system metaphor, "an overall story that everyone—customers, programmers, and managers—can tell about how the system works" [Beck]. The business selects the subset of stories that will form the next release and development makes a delivery commitment. Development splits each of the stories into a number of tasks. Each developer accepts responsibility for a set of tasks.
Replace stories with domain walkthroughs and tasks with features and it sounds very similar to the first three activities in FDD.
The enormous difference between XP and FDD is FDD's additional development of an overall domain object model. As developers learn of requirements they start forming mental images of the system, making assumptions and estimating on that basis. Developing an overall domain object model forces those assumptions out into the open, misunderstandings are resolved, and a more complete, common understanding is formed.
XP uses the analogy of driving a car. Driving requires continual little course adjustments; you can't simply point the car in the right direction and press the accelerator. A domain object model is the map to guide the journey; it can prevent you from driving around in endless circles. The domain object model provides an overall shape to which to add function, feature by feature.
The domain object model enables feature teams to produce better designs for each group of features. This reduces the number of times that a team has to refactor their classes to add a new feature. Reducing the time spent refactoring increases the time that can be spent adding new features.
Collective Ownership or Class Ownership?
XP promotes collective ownership of code; any developer can add to or alter any piece of source code as needed. But collective ownership usually degenerates into non-ownership as the number of people involved grows. Small communes often work; larger communes rarely work for any length of time. XP claims three benefits from collective code ownership:
We avoid waiting for someone to make a change we need in their code.
Overly complex code is eliminated because anyone who finds such code will try to simplify it. Knowing this, developers are less likely to add complexity that they can't justify.
Collective ownership spreads knowledge of a system throughout the team, reducing risk if a crucial team member leaves.
Feature teams also solve these problems, while keeping the well-established benefits of individual code ownership:
By definition, all the owners of classes needing updates for the development of a particular feature are members of the feature team. In other words, the feature team owns all the code that needs changing for a particular feature. This minimizes waiting for someone else to modify their code.
All low-level design in FDD is done within feature teams (Design by Feature). The irritating "development by surprise" problem, in which a developer delivers code that's different from agreed design, is caught at code inspection by the feature team and rejected. Overly complex code is caught in the same way, before it enters the system.
Although class owners work only on the classes they own, owners of closely associated classes frequently work in the same feature team. They get to know those closely associated classes. Knowledge is clustered rather than randomly scattered.
XP also assumes that short integration and testing cycles means a low rate of collisions from developers updating the same piece of source code. For larger numbers of developers and systems, this is obviously less likely to be true.
Inspections and Pair Programming
Design and code inspections, when done well, are proven to remove more defects than testing. Secondary benefits include the following:
Education. Developers learn techniques from each other.
Coding standard enforcement. Conformance is checked.
XP uses pair programming to provide a continuous level of design and code inspection. All low-level design and coding is done in pairs. This is obviously better than individual developers delivering code without any form of inspection.
FDD promotes more formal inspections by feature teams; the level of formality is left to the chief programmer's discretion. This takes more time, but it has added advantages over pair programming:
Fresh eyes to look at the code, catching bad assumptions made by the coder(s).
A chief programmer to ensure that the techniques learned are good techniques. Yes, developers can easily teach each other bad habits as well as good habits.
Change of pace for developers—an hour or so away from the terminal (assuming the common practice of printing source code for inspection).
There's no reason why members of feature teams can't pair up during coding when this is desirable. It's not unusual to see two members of a feature team working together where care is needed. One of the great things about feature teams is that a feature is complete only when the team is finished—and not when any one individual is finished. It's in the team members' own interest to help each other.
Testing
Correctness in XP is defined by the running of unit and functional tests. FDD takes unit testing almost for granted as part of Build by Feature. FDD doesn't define the mechanisms or level of formality for unit testing; it leaves the chief programmer to do what's appropriate.
It's acceptable to use XP unit testing techniques in an FDD environment. Where continuous or regular system builds are performed, it certainly makes sense to have a growing set of tests that can be run against a new build. Again, FDD doesn't specify this because technology and resources differ so much between projects. In some circumstances it's very difficult to produce a set of completely isolated, independent tests that run in a reasonable amount of time.
Reporting
XP leaves tracking to the project managers, encouraging them to minimize the overhead of collecting data and use large, visible wall charts. By contrast, Tracking by Feature in FDD describes a low-overhead, highly accurate means of measuring progress and provides the data to construct a large variety of practical, useful progress charts and graphs.