Thursday, October 21, 2004

Getting Back to FDD’s Roots

Over the course of this summer I’ve given 3 talks about The Coad Method’s Contribution to Agile and presented both on the evolution of Coad’s domain modeling techniques and the evolution of management techniques in FDD at the Borland Conference. FDD’s roots in the The Coad Method as described in Peter Coad’s 1995/1997 book Object Model: Strategies, Patterns and Applications has tended to be glossed over in recent years since the Agile Manifesto was written. For a while, any form of analysis and design was out of favor in the agile community. However, Eric Evans with his tomb, Domain Driven Design, has made the whole idea of domain modeling respectable in the agile community again.

However, it isn’t so much the domain modeling which I think is the unique innovation from the Coad Method in FDD but the very notion of a Feature as a fine-grained piece of client-valued functionality which can be developed in a short period of time - in my experience anything from 4 man hours to 8 man days with the mean around 10 man hours on projects of any size or scale beyond one or two developers. Features use a language template of <action> <result> <object>. This format lends itself to object-oriented implementation. The <object> is the class which will implement the method whose name is <action> and the <result> is the return value from the method. Every Feature maps to a single UML Sequence diagram (whether you choose to draw it or not). Features are very tightly defined.

As such Features enable a lot of things. Features are predictable and repeatable within a reasonable tolerance. Features are approximately the same size and both the effort involved, and the likelihood of defects can be estimated fairly accurately. Features are also a unique measure of work-in-process inventory. They enable a style of management and a mechanism for reporting which isn’t possible with tasks where there is no codification scheme. Features enable end-to end traceability. In the most agile of FDD implementations, Features are the requirements, and yet they map on to the analysis, and directly to a sequence diagram in the design. They name a method in the code and identify a class in the domain model. Features are transparent. Features are loosely coupled. Without Features, FDD is like any other iterative and incremental method of software development. With Features it is more like an MRP system for software engineering management whilst double timing as an architectural approach to building systems.

FDD is perhaps the first example of a domain model-driven agile process. As we move to a world of model driven design (Borland Together already does this and the forthcoming Microsoft Class Designer and Software Factories apporach follow the same lead) and its alternative model-driven architecture, FDD seems to be the only agile method prepared for the paradigm shift. This wouldn’t be possible without its roots in The Coad Method.

There is a lot more in FDD which dates to Peter Coad’s work in the mid-nineties. For example, the notion of “frequent, tangible, working results” was Peter’s slogan for much of the decade and it translated into the rule that an iteration should not be more than 3 months long without releasing working code. The notion of consensus dates to Coad’s work too - this time with Fred Racey as documented in The Coad Letter - Lessons Learned from Fred. Fred Racey had a big influence on FDD. The adoption of the Tuckman model for team working of “forming”, “storming”, “norming” and “performing” came from him. So did much of the advice on facilitation of domain modeling sessions, including team working norms and the use of “pluses and deltas” at the end of daily sessions.

Peter Coad was also teaching the use of Kano modeling for Feature prioritization. For some reason this didn’t get published until I included it in my own book but the idea of using a scale of 0..5 for how much you desire the inclusion of something and 0..5 for how badly disappointed you would be if it were missing was something Peter taught us in Singapore in September 1997.

Some people have suggested that FDD doesn’t need Peter Coad’s modeling techniques in order to work. They worry that inclusion of domain modeling is a barrier to entry and a turn off for the prospective agile developer. I just can’t agree with that point of view. I think it is true that any method which asks you to make a fine-grained plan, to batch the plan into work packages of approximately two weeks and to build the project incrementally from there, will lead you to success. However, FDD without domain modeling and without the Feature template of <action> <result> <object> looks like an asynchronous rendition of Scrum. As communicating around an asynchronous schedule is harder, it creates a barrier to adoption. It would be better to use Scrum and be done with it. The true innovation in FDD and the enabler that makes it so incredibly productive and such a great platform for continuous improvement is The Feature and Features date from The Coad Method in the mid-nineties. With the growing popularity of domain driven design, hopefully the agile community will take a closer look at FDD and try to understand it better - try to understand the value of its roots in The Coad Method and the agility that it enables.