Set unreasonable deadlines

Damon and I have been discussing how time constraints can encourage creativity. I hinted at this in my first NaNoWriMo post, and it’s something I’ve been trying on other projects at work. Of course the concept is all through what 37signals is doing.

A few weeks ago there was a web application I wanted to write. I estimated it would take a couple of weeks to knock in the basic functionality. A small project, but big enough that it would have to be juggled with other priorities. And the requirements would need to be discussed with other members of the team, which might mean a quick death at the hands of committee-led design.

Encouraged by Willie over that weekend, we said let’s just do it and see what happens. Monday morning I asked myself: could I implement most of the application… before lunch? Because if I couldn’t, the project would still probably be sitting at zero lines of code. Luckily the app was a simple discussion system, and Rails was a particularly good fit for it.

In the latest The Writing Show podcast, J Wynia talks about why NaNoWriMo works. He said the biggest problem writers are faced with is the blank page. NaNoWriMo forces you to start writing immediately, because otherwise you won’t have a chance of finishing 50,000 words in a month. And something magic happens when you’ve written the first sentence: before you know it stories and characters are flowing and you’ve got a half dozen pages or more. If you waited until the first page of the novel had been fully thought out in your mind, you’d still be looking at a blank page.

Kathy Sierra wrote about creativity on speed, but I take issue with part of her post. I see speed in development work (C++, Ruby, whatever) as a good thing when it forces you to do something you would not otherwise be able to do because the task was too daunting. But speed in art is something else entirely. The latter is the whole subject of Betty Edwards’ classic book Drawing on the Right Side of the Brain. The idea is that by working quickly (gesture drawing, for example), you draw on instinct and what you are seeing, and less on what you think you know about how something looks.

I was first introduced to this concept in animation through the books of Shamus Culhane. It resonated with me immediately not just because I knew it was true — it matched my own experience with life drawing — but because he first discovered this while working on an old 1930s Mickey and Pluto short (Hawaiian Holiday) that I remember fondly as a kid (I still have the VHS copy). In some ways the high-speed drawing technique works even better in animation because you are already talking about time. The faster you work the closer the process itself resembles the final product on screen.

While building software is definitely an art — especially the process of crafting the user interface, or just bootstrapping an idea from nothing through brainstorming — I don’t think programming benefits from speed in the same way that art does. With software development the main benefit you get from working fast is breaking through roadblocks, simplifying, and getting things done. The creativity is a result of forcing yourself to think of things in a new way.