A common assignment type in creative arts classes is to produce a work in a
specific style on a specific topic. For example, a poetry class might have to
write a href="http://www.uni.edu/~gotera/CraftOfPoetry/sestina.html">sestina about
vampires. A painting class may produce watercolor still lifes. A composition
class could write a three voice canon and a songwriting class will sometimes
write a silly song in the AAA form.
These assignments rarely produce commercially viable or artistically elite
work, but they’re effective at exercising creative muscles. I think that the
constraints enforce some editorial judgments. For example, if you had to choose
the right six words to describe vampires as in the case of the sestina, you’d
have to choose the right six words, if you wanted to write a good poem.
Consider also the case of writing a three-hundred word horror story, especially
if you edit it multiple times. Every new word requires the removal of another
It’s obvious that you can take this idea too far. Arguably, since there’s
already one good vampire sestina (see Neil
Gaiman’s Smoke and Mirrors), the subject’s tapped out. If you
have existing constraints, though, of color, form, line length, meter, or word
count, does that save your creativity for more interesting problems?
In the introduction to
href="http://www.oreilly.com/catalog/extprogpg/">Extreme Programming Pocket
Guide, I argued that successfully adopting XP requires adopting an attitude
of sufficiency. Instead of assuming that you don’t have enough resources to do
everything you think you need to do, assume that you have enough resources to
do what you can do — and scale back what you need to do to what you can
In a recent post to the XP mailing list, Ron Jeffries suggested that you can
practicing XP by adopting the practice of Small Releases. That is, if you
force yourself to produce a release every two or three weeks, you’ll need to
adopt most of the other XP practices (or reasonable equivalents)! You don’t have to make your customer upgrade every two or three weeks, but his needs should govern the choice, not the stability or quality (or lack thereof) of the code.
Even though I’ve been writing and writing about software for a while, I’m
still amazed at how projects can drag on and on until someone with authority
gives a final, drop-dead date. (Hey, open source development isn’t immune.
Witness the length of time between Debian GNU/Linux or Linux kernel stable
releases!) It often takes a burst of activity (and, unfortunately, a death
march or two), but the software finally arrives near the deadline.
I’m deliberately leaving aside the questions of quality, customer fitness,
stability, and maintainability from this argument — I think XP-like
practices definitely help here — but I often wonder lately if trying to
produce more frequent releases by doing everything except releasing more frequently is misguided.
Perhaps we don’t need long development times because software’s so difficult
to write. Perhaps software’s so difficult to write because we have such long
Thanks to Adrian Howard for the pointer to the mailing list
Not all artificial constraints are harmless, but could the helpful or neutral ones help us produce better software more reliably?