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 award–winning 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 modeling—they'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 tools—an important distinction. This makes sense—when 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 situation—sometimes 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 inclusive—with
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 flexible—you 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 users—even 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 limited—you'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.
Technological Tools
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").
|
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.
Evolutionary Combo
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 on—they 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 sketches—we 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 tool—even if it's a CASE tool—that 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 job—sometimes you'll find that means that you won't even use a tool at all.
