Not So Shocking...
TDD is incredibly popular, probably because it works very well in practice—so well that it has a near-religious following within the Agile community. DDJ's 2007 Agile Adoption Survey showed that customer testing is the fifth most valuable practice for agile teams and that developer-level TDD is sixth. When it comes to work products, developer tests are the third most valuable, after working software and source code, and customer tests are the sixth. The point is that there is broad-based support for TDD among Agile developers—that we're actually doing what we claim to be doing.
However, TDD isn't perfect. At the CEE-SET conference in Poznan, Poland in October 2007, a paper written by Maria Sinaalto and Pekka Abrahamsson entitled "Does Test Driven Development Improve the Program Code? Alarming Results from a Comparative Case Study" was presented. This paper summarized a research study into the effectiveness of TDD, and it found that TDD may produce less complex code but that the overall package structure may be difficult to change and maintain. Although other studies into the effectiveness of TDD had looked at code-level issues, and found that TDD helps to increase quality, this was the first one to look at higher level architectural issues. This new study appears to show that TDD is effective for "design in the small," but that we need another approach for "design in the large." These results aren't shocking at all because the focus on TDD is on detailed specification and validation, not on higher level issues. Clearly, we need to look beyond TDD for a solution to this problem.
Specification at Scale
Although TDD is great at specifying code at a fine-grain level, tests simply don't scale to address higher level business process and architectural issues. AMDD enables you to scale TDD through initial envisioning of the requirements and architecture as well as just-in-time (JIT) modeling at the beginning and during construction iterations. The principles and practices of the Agile Modeling methodology describe lean strategies for gaining the benefits of modeling, which are to think things through and to communicate ideas, without the pain of excessive documentation.
Yes, I realize that modeling is one of the dirty words in the Agile community, and any discussion of up-front modeling early in the agile lifecycle is tantamount to heresy. Yet, when you ask people in private what they actually do on real-world Agile projects, you discover that the vast majority of us are apparently heretics. DDJ's 2007 Agile Adoption Survey found that 77 percent of all Agile teams do a bit of up-front requirements and architectural envisioning to identify the initial scope and technical strategy respectively. Furthermore, it found that whiteboard modeling is the fourth most valuable practice and that whiteboard sketches are the fourth most valuable work product.
To scale requirements-level TDD, you must recognize that customer tests are very good at specifying the details, but not so good at providing overall context. High-level business process models, conceptual domain models, and use cases are good at doing so, and these work products are often created as part of your initial requirements envisioning and iteration modeling activities. Process descriptions and use cases can easily reference customer tests, or even be written as customer tests that in turn invoke other customer tests, to provide the business context required to understand the overall requirements for your system. The details are still captured in the form of tests, but the models provide the high-level context required to think through critical scoping and planning issues.
Similarly, to scale design-level TDD, you must recognize that developer tests are very finely grained but once again do not provide overall context. High-level architecture sketches created during your Iteration 0 envisioning activities help set your initial technical direction—a little bit of up front design work helps to avoid structural problems cropping up later in the lifecycle. During each construction iteration, you'll do more detailed design modeling, often sketching or using index cards to explore issues that tests aren't well suited for. Highly skilled developers will even use software-based CASE tools to do this sort of work, although the majority of developers will use IDEs such as Eclipse, Visual Studio, or Jazz.
