The use of simple modeling tools is a common thread among agile software development methodologies. Extreme Programming (XP), the most popular agile process, promotes the use of index cards to record user stories, development tasks that describe the user stories in greater detail, and Class Responsibility Collaborator (CRC) modeling to explore software design. Alistair Cockburn, in his new book Agile Software Development (Addison-Wesley, 2002), argues that the most effective means of communication, including modeling activities, is a face-to-face conversation at a whiteboard. In the Jolt awardwinning Software for Use (ACM Press, 1999) Larry Constantine and Lucy Lockwood describe how to use sticky notes and flip-chart paper to explore the user interface of a system with its users. The trend toward simple tools is so prevalent that several readers have nominated index cards in the Software Development Jolt Awards Design and Management Tools category this year. Does this foretell impending doom for CASE tool vendors? Perhaps, particularly for those tool vendors that are unable to support the agile methods that many developers are now choosing to employ.
First and foremost, I want to make it perfectly clear that agile developers don't limit themselves to index cards and paper napkins when they're modelingthey'll also use software-based tools whenever appropriate. In fact, in the Agile Modeling (AM) methodology, I specifically included a practice named Use the Simplest Tools to address this very issue. Notice that I recommend using the simplest tools, not just simple toolsan important distinction. This makes sensewhen you're following practices such as Create Simple Models and Depict Models Simply, the models you're creating don't have a lot of residual value once they've fulfilled their purpose, which is typically to explore or understand an issue or to communicate an idea to someone else. Furthermore, because agile modelers follow the practice Discard Temporary Models, it doesn't make a lot of sense to invest extra time modeling with a CASE tool. Sometimes, however, simple tools aren't sufficient. If you need to create a "pretty" diagram to present to important project stakeholders or want to generate source code based on your models, more complicated CASE tools make sense. In short, agile modelers use the simplest tool possible, depending on the situationsometimes that's a whiteboard and sometimes that's a leading-edge CASE tool.
'Tis a Gift ...
Why would you want to use simple modeling tools? Simple tools are inclusivewith them, even your project stakeholders can actively participate in your project. Simple tools also provide tactile feedback and can be easily manipulated. Simple tools are flexibleyou can easily write on an index card, move it around, and, when you no longer need it, simply rip it up. The same thing can be said of sticky notes, napkins and sheets of paper. Simple tools are nonthreatening to userseven if someone's afraid of losing a job to a computer, nobody's nervous about a stack of cards.
Simple tools are also well-suited to both iterative and incremental development, in which problems are tackled a small portion at a time. For example, with index cards, it would be easy to explore the internal structure of a component, perhaps comprising 20 or more classes. Finally, simple tools promote traveling light, because it's much easier to discard an idea that hasn't taken much effort to elucidate.
When Simplicity's Insufficient
Simple tools also have their weaknesses. First, simple tools aren't acceptable to many people. Developers who are used to creating models using complex CASE tools may not believe that whiteboard sketches or a stack of index cards can be sufficient for their modeling needs. Users who have become accustomed to sophisticated and detailed requirements documents describing their systems may not understand that the requirements can be described in a little box of cards. Second, simple tools are limitedyou're not going to be able to automatically generate Java source code from a stack of index cards. Third, simple tools aren't well-suited to permanent documentation. Although a box of cards might sufficiently capture the requirements from the point of view of the people who created them, the cards probably aren't sufficient for non-team members, or those who may try to understand the system several years later. You'll find that you still need to use more complicated tools, such as word processors or CASE tools, to create permanent documentation. Fourth, simple tools do not easily support distributed teams. Because simple tools are physical, team members need to be in the same location at the same time to work with them. Yes, you can use electronic whiteboards and conceivably teleconference people into your working session, but that can't quite produce the spontaneous interchange that occurs when a team hunkers down over a pile of cards on the same desk.
To circumvent these deficiencies, you may choose to use technology-based tools to create a permanent record of your work or to share information with people at other physical locations. I will often use a digital camera to take a picture of a whiteboard or a scanner to record paper-based artifacts. Though the picture quality is less than desirable, fortunately, a product called Whiteboard Photo from Pixid (www.pixid.com) can be used to enhance image quality and to convert images to a format suitable for optical character recognition (OCR) software. For example, I used Whiteboard Photo to clean the first image of a UML deployment diagram, producing the second image in less than one minute (see "Picture Perfect").
Electronic whiteboards are also a popular technological tool. They range in capability from Panasonic's (www.panasonic.com) Panaboards, which simply produce a paper copy, to more sophisticated tools such as TeamBoard (www.teamboard.com) and PolyVision's Webster (www.websterboards.com), which integrate with potentially collaborative software such as Microsoft's NetMeeting to share your work online with distributed team members. Mimio (www.mimio.com), a portable scanner that you simply attach to existing manual whiteboards, is another interesting option.
Agile modelers will also use word processors, text editors and HTML editors to capture text-based information, particularly when they require sophisticated editing capabilities. Another common tool is a Wiki (www.wiki.org), a collaborative environment used to coauthor HTML-based information. Think of a Wiki as a Web site that comes with its own tools and lets authorized users edit, add and remove pages. Development teams use Wikis to grow their group memory, recording their requirements artifacts, key architectural and design decisions, and shared documents. Wikis support AM's practice of Open and Honest Communication as well as the practice Display Models Publicly.
Simple tools can also be used in combination with more complex ones. Agile modelers typically start a project by discussing an issue that they're working on; sometimes that discussion is sufficient, and they can move forward and start writing code. The majority of the time, however, they'll choose a simple tool and work together, following the practice Model With Others. Changing tools as they see fit, they may begin with index cards and then move on to a CASE tool once their understanding of the issue stabilizes.
Why take this evolutionary approach? Why not just use a CASE tool right away? In the early stages of exploration, agile modelers need a very flexible tool that will enable them to quickly change the model they're working onthey don't want to invest much time at the start, because much of their initial work will be discarded as their understanding evolves. For example, modelers will often use sticky notes to explore the design of a screen or page because they can represent widgets that can be moved with ease. As their vision for the screen stabilizes, they can increase the work's fidelity by moving to a whiteboard to identify widget types, such as drop-down lists or edit fields, as well as relative sizes. To move to the next step, producing a detailed user interface prototype or even the production source code itself, they'll use a development tool to tighten up the design to reflect corporate user interface standards and the system's actual technical environment.
Stickies and Sketches
Why use tools at all? Why not jump straight to code? First, code isn't as flexible as either sticky notes or whiteboard sketcheswe can't move things around in code as easily as we can with sticky notes, and we probably can't change widget types as easily as we can sketch. In short, a few minutes working with sticky notes or drawing some sketches will probably pay for itself several times over in saved coding time. Second, because stickies and sketches are more inclusive than code, nondevelopers like your direct users will understand and become actively involved with the UI design process of the system you're building for them.
The Big Guns: CASE Tools
Sometimes, however, you've gotta get out the big guns. Common CASE tools include TogetherSoft's (www.togethersoft.com) Together Control Center, Canyon Blue's (www.canyonblue.com) Cittera, Embarcadero's (www.embarcadero.com) ER/Studio, Gentleware's (www.gentleware.com) Poseidon, and Rational Corporation's (www.rational.com) Rational Rose. In accordance with the practice Maximize Stakeholder Investment, any tool, including a CASE tool, should be used only when it's the option that provides the maximal value for your investment in it. Furthermore, the practice Develop With a Purpose suggests that you should know why you're creating an artifact. This knowledge will determine the extent of the work that you need to perform to complete your model, so that you'll stop as soon as your model fulfills its purpose. And, in turn, this awareness will provide insight into the functionality you require of your tools. By anticipating your actual requirements, you can then determine which tool will actually provide the greatest value for your project. My experience is that a gut-feel approach to choosing your tools is often the most effective method, albeit one that senior management may not trust you to take.
AM's practice Use the Simplest Tools may seem obvious, but it's important to remember to select the most simple tooleven if it's a CASE toolthat will do the job. When the job is exploring the requirements for your system, a simple tool such as a whiteboard or stack of index cards is your best option. When the job is producing working software, a tool that generates and reverse-engineers source code is a better choice. Choose the tool that fits the jobsometimes you'll find that means that you won't even use a tool at all.