The efficacy of time-constrained hacking

Friday’s successful “hack day” experience is still fresh on my mind and a couple of blog posts popped up on my radar today that
reflected some of the philosophical underpinnings of our event. A post from David Heinemeier on the 37Signals blog (“Constraints breed breakthrough creativity“) pointed me over to Kathy Sierra’s post entitled “Creativity on speed.” I’ll quote the same section that David did because it’s so on the mark:

One of the best ways to be truly creative — breakthrough creative — is to be forced to go fast. Really, really, really fast. From the brain’s perspective, it makes sense that extreme speed can unlock creativity. When forced to come up with something under extreme time constraints, we’re forced to rely on the more intuitive, subconscious parts of our brain. The time pressure can help suppress the logical/rational/critical parts of your brain. It helps you EQ up subconscious creativity (so-called “right brain”) and EQ down conscious thought (“left brain”).

I totally agree, and I’m glad that Kathy stated is so well. I feel fortunate that early in my engineering career (both as manager and coder), I worked in environments (like a big sports site that I and my team built from the ground up) where we weren’t shipping software as much as we were shipping experiences around very specific — and totally inflexible — events. When you’re dealing with sporting events, you can’t not ship. The World Series, Olympics, and Super Bowl happen whether your code to provide the experience is ready or not. In that environment, I learned that sometimes you really have to ship. Sometimes there literally is no more time — no one is going to postpone the World Series because your code isn’t quite ready. I also learned that if you have the right team in place, the team often does its best work under this intense time pressure. That’s why I had a strong hunch that some really cool things were going to happen at our hack day, and they did. As David writes: “Don’t worry about having more time, build less software.” If you can’t build less software (e.g. you have to have scoreboards for the World Series), build what you have to build in the simplest possible way — another practice that was clearly in effect at our hack day.

The end of Kathy’s post suggests a compelling structure for a two-day hacking event that I’m going to file away for future reference:

It would be fun to see a combination camp where the first half of the weekend was about actually making something, solo or collaboratively, and the other half was about exchanging ideas with the other participants (including the things you made during the first half, and lessons learned).

Sounds like a great idea. . . .

(Also, don’t forget to read Kathy’s “Build something cool in 24 hours“)