Summary
Most of us wish for more time, bigger budgets, and more help in completing projects. Could that be wishing for the very things that push us further away from success? Should we, instead, wish for shorter deadlines, less people to work with, and even for smaller budgets?

Among the most familiar tunes you will hear played over and over on radio stations this holiday season are from Händel's Messiah. While that music is familiar to most ears, a less known fact is that Händel wrote the entire two-and-a-half-hour work in a mere twenty-four days. He had to, mainly to alleviate his pecuniary troubles at the time. Fast-forward about eighty years, and we witness Rossini poring over the score of his new opera, The Barber of Seville—but not for long, for he completed the entire two-act work in just under three weeks.

While it's easy to attribute to sheer genius such creative feats, is it really the case that only a select few can create good work under extreme time constraints? Or, does perhaps the contrary hold: That strict time constraints actually enhance creative output by making us more productive?

Kathy Sierra's recent blog entry, How to make something amazing, right now, entertains the latter notion:

What if you needed to build a powerful web app, but you had only ten hours a week for programming? What if you wanted to write a novel, but you had to do it in 30 days? What if you wanted to create a computer game, but you had only 48 hours? What if you had to write, shoot, and edit a short film in 24 hours? Constraints can be your enemy, but when it comes to creative breakthroughs, they can be your best friend.

The folks at 37 Signals—who gave us Ruby on Rails, Basecamp, and other Web-based goodies—seem to agree. In a recently published pamphlet, Getting Real, which they make available on their Web site for purchase as a PDF (Disclaimer: I am in no way affiliated with 37 Signals), have this to say about constraints:

Constraints ... force you to get your idea out in the wild sooner rather than later... A month or two out of the gates you should have a pretty good idea of whether you’re onto something or not. If you are, you’ll be self-sustainable shortly and won’t need external cash. If your idea’s a lemon, it’s time to go back to the drawing board. At least you know now as opposed to months (or years) down the road. And at least you can back out.

Later in the booklet, they talk about the trade-off between scope, time, and budget:

Here’s an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope. There’s a myth that goes like this: we can launch on time, on budget, and on scope. It almost never happens and when it does quality often suffers. If you can’t fit everything in within the time and budget allotted then don’t expand the time and budget. Instead, pull back the scope. There’s always time to add stuff later—later is eternal, now is fleeting.

Of course, the reality is that every project, every company, and every developer, operates under some constraints—there are no infinite budgets, infinitely patient customers and bosses, or eternally long lives. But most of us would naturally want to make those constraints as broad as possible. Who would not welcome more time to finish a project, increase the budget, and add a couple of new hires to get some of those unfinished chores finally done?

Does the natural tendency to seek lesser constraints actually put us further away from success? Kathy Sierra in the aforementioned post writes that,

I wanted to emphasize again that it's not just about inspiring (or forcing) creativity, it's also about getting something done. How many of us keep planning to get around to writing that book... once we've got some free time? How many projects stay on the back burner forever because we just can't seem to make it happen? The creativity-on-speed format can change that, especially if you have support from a group of people doing the same thing.

She talks about The Shootout Boulder, a 24-hour film festival, where each participant is given 24 hours to produce a movie, with the next day being spent judging the results. She also mentions November as the National Novel Writing Month, where you can still sign up to complete that always-planned novel in just thirty days.

Short deadlines often conjure up the image of poor quality output, but that does not have to be that way, according 37 Signals' Getting Real: Instead of sacrificing output, limit scope, but live with—and love—the constraints, says their booklet. In other words, you can always create something high-quality in a very short time. And, according to Sierra, that output may actually be more creative than if you were given much wider latitude in the schedule.

How the Messiah or the Barber of Seville would have turned out if their composers were given two or three times more time, we will never know. But here is a thought-experiment that can yield some worthwhile insight: To what extent would your daily work be different if you were given two or three times less time for the projects you're working on? What decisions would you make differently in terms of the architecture or tools you use, or in the scope of the work? Do you feel you would be more creative in solving the problems you are working on if you had to produce a solution within a more limited time?

Talk Back!

Have an opinion? Readers have already posted 25 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.