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?

Advertisement

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?

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?

I think the main point Kathy Sierra and the 37 Signal guys were making is that it's often better to ship something today than to wait because you want to implement the full set of functions you envisioned for a project. Their second point is that whatever you ship today, should be of high quality.

Clearly, a word processor without the ability to save files is not very useful. But if you look at Writely, for instance, they certainly don't offer half the features MS Word has, yet enough people found their product useful for Google to realize the value in that product and purchase the company. As far as I recall, they had even less features when they first released the product. However, the few features they did have, were of high quality.

The little booklet by the 37 Signals people also states somewhere that the hallmark of a seasoned developer is to know how to cut scope, i.e., to know what features are essential and what can be added later. Of course, that pre-supposes that you have the freedom as a developer to decide what features go into a release.

However I agree that references to Händel's Messiah or other artistic enterprises don't really further our understanding of software or software projects. It seems many software developers are wannabee scientists or wannabee artists, struggling with the disappointment of engineering or craft work.

> I think the main point Kathy Sierra and the 37 Signal guys> were making is that it's often better to ship something> today than to wait because you want to implement the full> set of functions you envisioned for a project. Their> second point is that whatever you ship today, should be of> high quality.> > Clearly, a word processor without the ability to save> files is not very useful. But if you look at Writely, for> instance, they certainly don't offer half the features MS> Word has, yet enough people found their product useful for> Google to realize the value in that product and purchase> the company. As far as I recall, they had even less> features when they first released the product. However,> the few features they did have, were of high quality.

Cough, cough, do you think that MS Word had half the features it has now when it first shipped?

"were of high quality" - whatever that means!

> The little booklet by the 37 Signals people also states> somewhere that the hallmark of a seasoned developer is to> know how to cut scope, i.e., to know what features are> essential and what can be added later.

> Of course, that pre-supposes that you have the freedom> as a developer to decide what features go into a release.

> I think the main point Kathy Sierra and the 37 Signal guys> were making is that it's often better to ship something> today than to wait because you want to implement the full> set of functions you envisioned for a project. Their> second point is that whatever you ship today, should be of> high quality.

I get rather frustrated by a pattern that seems common these days. Someone will make a very broad and shocking claim and when somebody finds flaws in it, it suddenly morphs into something that sounds more reasonable. I guess that sometimes the desire to get attention is greater than the desire to honestly present ideas.

Companies have been making trade-offs between content and release date for over 30 years, it's only the shocking claims that are new.

> > afaict Art can be flawed, mediocre, or otherwise> > unsuccessful.> > > > Sure, but bugs have a specific technical meaning. A> program can be flawed, mediocre, and unsuccessful and> still be bug free.> > > "The Inmates Are Running The Asylum" suggests that> > software projectsshould be run like> making> > a movie, p225 1st edition.> > These days there's no shortage of "high concept" software> development novelties, but when you dig deeper you find> that they are based on very poor analogies or a lot of> unsupported assumptions.

Have you actually read the relevant passages from "The Inmates Are Running The Asylum"?

If I were given less time to work on a project, I would leave. I wonder what universe 37 signals hails from that they make such broad unsubstantiated claims and have legions of people ready to jump and nod their way to orgasm in agreement. This reminds me, I wish Hani Suleiman blogged more.

> Have you actually read the relevant passages from "The> Inmates Are Running The Asylum"?

Well, there was certainly nothing relevant to this discussion in the link you provided. I'm not going to rush out and buy the book just for this discussion.

You brought the book up, not me. If you think there's a compelling argument in his book why software development should be like making a movie, why don't you tell us what it is? It's your argument, it should be your research.

> > Have you actually read the relevant passages from "The> > Inmates Are Running The Asylum"?> > Well, there was certainly nothing relevant to this> discussion in the link you provided. I'm not going to rush> out and buy the book just for this discussion. > > You brought the book up, not me. If you think there's a> compelling argument in his book why software development> should be like making a movie, why don't you tell us what> it is? It's your argument, it should be your research.

I don't think you should rush out and buy that book just for this discussion. However, you chose to reply with a generalized criticism apparently aimed at that book: "These days there's no shortage of "high concept" software development novelties, but when you dig deeper you find that they are based on very poor analogies or a lot of unsupported assumptions."

If it was your intention to criticize something you haven't seen then I think we should conclude that you literally don't know what you are talking about.

> If it was your intention to criticize something you> haven't seen then I think we should conclude that you> literally don't know what you are talking about.

I wasn't my intention to criticise the book as a whole, but to criticise one idea that you claim was in it. Merely stating the Joe Blow has a different opinion in some book without elaborating on Joe's point or linking to it is not much of an argument and shame on me for giving it more credibility than it deserves. I promise I won't make that mistake again.

>> However I agree that references to Händel's Messiah or> other artistic enterprises don't really further our> understanding of software or software projects.

To the contrary, I'd argue that observing the habits of any highly productive person can benefit developers and software projects. In these specific examples, several observations are relevant to software projects:

* Both composers got paid for results, not for the number of hours spent or a fixed salary.

* They had to meet non-negotiable deadlines.

* Their work was ultimately judged by their "users" (audience), not by their peers. Thus, they had to be concerned about the UI the most (the effects the work would create on the audience), and not so much about the techniques or tools to achieve those effects.

* They had to choose techniques and tools with execution in mind: The performers had to be able to easily execute what the score instructed them to do, i.e., they had to use familiar techniques.

* In these examples, they did not aim to break new ground, but rather to meet the objectives of (a) pleasing their "users", and (b) meeting their deadlines. Instead of re-inventing the wheel, they re-used much earlier material, and stayed within the confines of well-known frameworks.

* While they followed conventional frameworks, they added flourish and originality at certain places to improve "usability" (to please their audience).

These are just a few observations in this context, and the way it applies to developers and architects are rather common-place restatements of what has already been said so many times and in so many books and blogs:

* If you project's success is judged by how pleased users are with it, focus on usability, and don't worry about what techniques or frameworks to use to achieve those effects.

* If you want to complete your project in time, don't break new ground, but simply imitate what has worked in the past, step-by-step. Follow a well-oiled formula, i.e., use a framework.

> If I were given less time to work on a project, I would> leave. I wonder what universe 37 signals hails from that> they make such broad unsubstantiated claims and have> legions of people ready to jump and nod their way to> orgasm in agreement.

I don't think their aim was to have people blindly follow them, but simply to share what worked for them in the past.

Allocating less time for a project would also mean cutting the scope of the project. Many XP books and articles talk about the importance of shipping, and shipping something today, if possible. The idea is that if you ship something every day, you don't work in a vacuum, but get some kind of feedback from users early. A "project" can be as tiny as changing the aligment of text on a page, or fixing a bug or two. Only with that reduced scope can you have both quality and quick turn-around. (That's kind of obvious.)

I know several large Web-based companies that ship their code (release a new version) every two or three weeks. When you are bound by that hard deadline, you need to focus on what can get done within that time-frame, and determine project scope accordingly.

Tight deadlines (with appropriate scope) have the effect of creating focus, but shipping often has a psychological effect, too - that of sensing progress. In the past I worked on projects that we'd release only once every several months, and there was something isolating about that. I'd rather have daily communication with users based on recently shipped new features or bug fixes than waiting for months to get that feedback. You can instantly see whether you're on the right track and, if not, change course quickly.