I had a previous
life in literature. That is, I spent a number of years as an English instructor
and professor. I was especially excited about the idea that the traditional
“canon” of literature—you know, the “great works” of literature—was being
challenged and re-written. The idea that historical and cultural forces have
shaped what we considered “good” literature was revolutionary to me. I’d always
been taught it was some ideal aesthetic state or ideal “truth” that made
certain writings rise to the top. So it was OK to see African American, women,
and other writers as part of “great” literature. Innovation replaced tradition
as a dominant mode of deciding what’s relevant in art.
But what on earth am
I getting at, you wonder, on a blog specifically designed to address
application definition?
In the world of the
Web, we have been innovating for years in terms of content, functionality,
usability, cultural specificity and diversity. In the world of application
definition, I think we’re a little behind. We have clung to modes and methods
of application definition that often don’t contribute to a better, more
innovative system. We spend much of our time on documentation that’s never
read, just because it’s what we’re used to. Even when visualization with iRise
is a huge success, we scramble to backflush the simulation with use case
documents, and other requirements--documents that, in many cases, are simply no
longer needed—to say nothing of how well written or clearly worded these
documents may or may not be.
Too many times at
large corporations, I’m asked to create numerous documents that literally NO
ONE ever reads—and are never crucial to development. Some of it is, in fact,
desperately needed and essential to development, but I argue that most of that
can be done simply using rapid prototyping, using iRise. Functional
requirements documents, use cases, business requirements documents—MUCH of it
can (and should) be eliminated.
The value proposition of rapid prototpying with iRise to my mind is this: streamlining the application definition process in such a way as to provide exactly what is required is less time, with fewer resources, and less extraneous and confusing documentation.
While writing this
entry, a colleague told me about a booklet put out by 37 Signals called Getting Real (see http://gettingreal.37signals.com).
Though its scope is much larger than just documentation, it has a section in it
on “Words” that I swear was written for me. It has such appealing section
titles as “There’s Nothing Functional About a Functional Spec” and “Don’t Do
Dead Documents.” They argue for the relevance and flexibity of more organic and
interactive methodologies. I would argue that rapid prototpying with software
such as iRise fits the bill.
Let’s work to revise the requirements documentation canon—think radically and innovatively about application defintion. Don’t just use prototyping in addition the piles of documents no one will ever read. Use it in lieu of many of those documents. Like we’ve done with expanding our ideas about what constitutes great literature, let us also then expand and revise traditional documentation with more innovative modes of discourse that are inclusive, dynamic—and that generate great precisionand adaptibility in, and excitement about, the systems we define and build.
