In This Issue
- Model Storming Before Testing
- Book Review: Journey to Data Quality
- Hot Links
Model Storming Before Testing
Test-driven development (TDD) has taken the agile world by storm. Rightfully so -- it's an incredibly effective technique. TDD promotes confirmatory testing of your application code and detailed specification of that code. Customer tests, also called "agile acceptance tests," can be thought of as a form of detailed requirements and developer tests as detailed design. Having tests do "double duty" like this is a perfect example of single sourcing information, a practice which enables developers to travel light and reduce overall documentation. However, detailed specification is only part of the overall picture -- high-level specification is also critical to your success, when it's done effectively. This is where Agile Model Driven Development (AMDD) comes in.
In previous newsletters I've discuss the initial modeling efforts which occur during "Iteration 0" of an agile software development project. At the beginning of a project you need to do just enough modeling to understand the scope of the system and to identify the initial architectural vision for the system. In this newsletter I want to explore the relationship between just-in-time (JIT) detailed model storming which occurs during construction iterations and the detailed specification effort which occurs as part of TDD. On disciplined agile projects, particularly those which need to scale beyond a handful of people co-located in a single room, AMDD and TDD go hand-in-hand.
Customer tests are one form of detailed requirements specification, a particularly effective one considering that it also validates the requirement (if you're using the right tools). However, sometimes we need more than a detailed definition. Models, in particular those which explore usage such as use cases, provide context for the customer tests. A single use case could encapsulate 10 or more customer tests, showing how they interrelate with each other and more importantly providing motivation for further acceptance tests which validate a complete business transaction.
Other models provide important views which text-based customer test can never hope to address. For example, a user interface sketch or prototype can be used to explore the layout of a screen whereas a user interface flow diagram explores the flow between screens. Because the user interface is the system to the vast majority of end users, these models can be critical to create because they reveal potential usability problems long before a line of code is ever written.
I want to be perfectly clear about the fact that you don't need to create these models up front, nor do you need to invest a lot of time creating them in detail. Instead you can create them in a JIT manner via model storming to the level of detail that you require at the time. A model storming session typically lasts just a few minutes -- several people get together in an impromptu manner, explore an issue, and then continue doing something else. For example, on an Extreme Programming (XP) project you might pick a user story off the work queue which is worded something like "Capture the Shipping Address Upon Checkout". It would be reasonable to model storm with your stakeholder(s) for a few minutes, drawing a whiteboard sketch of what this part of the user interface should look like. Once you're satisfied that you understand the requirement, you then identify a related customer test and implement enough code to fulfill that test. You would iterate through writing a test and then enough code to fulfill that test until the functionality is fully implemented. The model storming effort may take between 5 to 10 minutes and the TDD-based implementation several hours or even days. Yet that simple model, merely a hand-drawn sketch, would capture the critical thinking required to ensure success which wouldn't have easily been captured in the customer tests. In other words, there's still value in modeling.
On the design side of things sometimes a model can provide important context for your development TDD efforts. Design models enable you to think through issues before diving into the code, thereby avoiding costly mistakes. This doesn't mean that you need to do a lot of detailed modeling up front: some whiteboard sketching to explore several alternatives before jumping into coding can save days, and sometimes weeks, of effort going down the wrong technical path.
My main point is that AMDD enables you to think through high-level issues whereas TDD is well suited for the detailed issues. The secret is to apply the right technique for the situation at hand -- sometimes you want to create a model, sometimes you want to write a test. TDD is a wonderful development technique, very likely one of the most important ones to come our way in quite a long time, yet like all other techniques it's limited in scope. AMDD addresses the weaknesses of TDD, and AMDD would be little more than drawing pretty pictures without development techniques such as TDD.
Although I've mentioned whiteboards several times, my experience is that whiteboards are one of the most effective tools available to a development team, this doesn't say that you can't model storm using sophisticated modeling tools as well. If you have the modeling tools available to you, and the skill to use them properly, then you can dramatically increase your overall productivity. But that's a topic for another newsletter.
