Outside-In

What do these things have in common:

1. The People's Republic of China
2. Smucker's line of "100% Simply Fruit" spreads
   
3. Scrubs will be right back after these messages

They all follow Brandon's Rule: If it's on the outside, it's not on the inside.

China is not a Republic, that Smucker's line is 30% juice, and there's no more Scrubs after the final commercial break.

When something is true, you don't need to announce it. You don't need to convince people of it. You don't have to draw attention to it.

Here's some more:

• We put customers first.
• We treat customers as partners.
• We have unmatched customer support.

The quality of customer support is something you notice right away. Either they answer the phone quickly, or they don't. Either the person on the other end genuinely helps you, or they don't. Either your "account manager" continues to provide service after the sale, or she doesn't.

I can't count the number of times I've heard a C_O say "What distinguishes us from our competitors is better customer service." Theoretically, having good service is not only a competitive advantage, it's also the primary way to develop solid relationships, promote word-of-mouth advertising (the best kind), and can even make a sale even when the first impression was unfavorable.

But you can't convince people you have good support by telling them so. In fact, telling them so might turn them off.

Here's what I tell folks in demos: "While you're trialing our software, also trial our tech support. Give 'em a call and test it out. Make sure we're responsive and helpful."

When you hit someone over the head with honesty, it leaves a mark. People are so used to hearing things like "We have unbeatable customer service" and "Customer service is priority number one," the words are water off a duck's back. Even if true, they're meaningless.

So when I tell them to try it for themselves, I get amazing reactions. "Wow," someone recently told me, "I've never had a vendor actually encourage me to call them for support." My response was: "Well, I could tell you we have great customer service, but you wouldn't believe me." His response to that: "I don't have to call. I already know you guys are going to rock."

When was the last time you built that kind of relationship with a potential customer during the initial demo? Just by being honest.

So don't say it, do it. Encourage potential customers to notice, but let them come to their own conclusions.

Microsoft isn't scary anymore

There, I said it.

Today, if Microsoft announced a direct competitor to Code Collaborator, I don't think it would affect our sales at all. And if they actually shipped a competitor, I don't think we'd notice that either.

In the 90's, a pre-announcement by Microsoft of a non-existent product could destroy a product line. The demise of Turbo Basic was an example (although in retrospect it was probably dead anyway...).

But now it's clear that Microsoft can't release a major product. As a shipping date approaches, the list of features shrinks, the new ship date is later, and betas never seem to settle down into stability. To this day Visual Studio devotees are easily amazed by features in other IDE's that have been around for years.

Compound that with Microsoft's self-imposed cross-product dependencies (e.g. Team Foundation Server, SQL Server), and now a slip in one component slips the others.

With each passing year we get fewer requests for Visual Studio plug-ins and more for Eclipse. With each passing year we continue to get requests for support in the latest edition of NetBeans but Visual Studio 2005 is still on the cutting edge for most of our Visual Studio customers.

If VS 2005 is still the most relevant Microsoft development platform, and as a percentage of serious development shops its share is decreasing, than how worried would I have to be to see a competitive product in VS 2008? Or one announced for VS 2009? When will that ship? And will that also take 3-4 years for adoption?

If anything it would help. Any press Microsoft can muster for a competitive feature means some people might be interested or convinced of its usefulness. Then with any Google searching they'll find us doing it nicely, available today.

So, oddly, I hope Microsoft tries to compete with us!

P.S. This is not meant to imply "Microsoft's death is inevitable." Microsoft is a big company with many factors determining its health and trajectory and lifespan. But they sure seem to be losing their grip on software developers.

Jolt Finalist: Code Collaborator

Code Collaborator has just been announced as one of six Jolt Award finalists in the category of "Collaboration Tools."

The competition is varied -- everything from wiki's to project management to collaborative development (us!). Hopefully, since this is a programming award, collaborative software development will be more relevant than general wiki's, but we won't know until March 5.

Not in the cards

Jeff Atwood recently posted an amusing treatise about shuffling cards demonstrating how sometimes the simplest algorithm isn't the right one.

Remember those open-ended interview questions that make you think deeply about a problem? Sometimes you actually need to do that in your job; it's not just an interview trick!

Card shuffling made me think of a similar, more common, and more complex problem of the "Shuffle Playlist" or "Random Slideshow."

(In the 90's we used to joke that "Every application grows until it becomes its own operating system." During the bubble we used to joke that "Every application grows until it is capable of sending and receiving email." Today I think the joke should be: "Every physical device grows until it is capable of playing mp3's or displaying pictures at random.")

The goal of the shuffled playlist isn't the same as shuffling cards. With cards it's sufficient to have a "randomized deck," meaning that every possible ordering of cards has an equal likelihood of being output by the shuffle algorithm.

The reason playlists and slideshows are more complex is: The goal is to make a human feel like the order is random, not to have it actually be random.

What's the difference? Imagine you have 5 songs. The algorithm for choosing the next song is to select one of the songs with equal probability and play it. Obviously this is completely random mathematically. Chi-squared will be happy.

But a human won't like it. It won't be uncommon (20% of the time) for the same song to be played twice in a row. Sometimes (1%) it will be played three times in a row! But that's not really what you want when you put songs on shuffle.

With an image slideshow it's worse. You're expecting images to change every 5 seconds (say), and sometimes it seems to get "stuck" (because the same image comes up twice in a row). Crappy slideshow player! Get a new one.

The usual fix for this is to take the entire playlist and randomize the order of the songs, rather than randomizing each selection of song. This ensures we have the perception of random distribution of songs. In fact it's not random at all by any mathematical definition. It's an even distribution, but not random one.

But that's OK, it's perception that counts. But we're not done! What happens when we go through the playlist once? You'd probably propose we just repeat the algorithm -- reshuffle the playlist and keep going another round -- but it's now still possible to repeat a song. The last song from the first shuffle might be the same as the first song of the second shuffle. A repeat!

In fact, the perception is probably marred even if any songs match near the "crease" between two shuffles. For example, if the last song of the first shuffle matches the second song of the second shuffle, that's probably still too close to "sound random." "I just heard this song!" exclaims the disgruntled, indignant user. And rightly so you bastards!

So now what? With larger playlists, you could start with a full shuffle, then take the last N (or N%?) of the first shuffle and check the first N of the second, and if there are overlaps you could swap songs from that initial "unsafe" region into the "safe" region, at random, being careful of course to swap only with songs allowed in the unsafe region.

"Wait," you cry, after having digested Jeff's excellent reasoning for why selective swapping is clearly for dummies, "that's not random!" No, it's not, and no one cares, because it's doing the Right Thing.

OK, so this swapping idea isn't great -- you can't do my version in place (because you have to remember the unsafe songs) and it's complex. Here's a simple, in-place algorithm:

1. S == number of songs, N == number of "unsafe" songs, meaning the last N of the first shuffle must not match any of the first N of the second shuffle.
2. Starting with the first shuffle, shuffle songs 0 through S-N. (This ensures that, at least, the first N songs are evenly selected from the set of songs allowed to be there.)
3. Now shuffle songs N through S. (This ensures that the unsafe songs are evenly distributed in the safe area.)

The keen eye will notice that if N > S/2, this algorithm fails. Indeed, you cannot satisfy the constraints in that case no matter what the algorithm because there's not enough "safe" songs to fill the "unsafe" region. As a simple example, if N=9 and S=10, we have only one song that is safe and nine unsafe slots to fill!

It's even worse for small playlists. With two items, the best you can do is alternate. With three, I would argue the best technique is to just keep any back-to-back's from happening -- anything more strict and you end up with zero variation, which doesn't feel like a "shuffle."

And don't think I'm being pedantic in calling out the cases of 2 and 3! That electronic picture frame on Grandma's sideboard might very well be displaying just 2 pictures, especially when you're first setting it up for her. First impressions are important!

So what's the lesson? In most applications, human perception is more important than mathematical correctness. And sometimes it's worth digging into your interviewee skills to cover a problem as deeply as you can.

In this case, a user unsatisfied with "shuffle" might not buy, might return the item, or might call tech support. A little thought and common sense could save many thousands of dollars.

Oh yeah, that's why great developers are worth a lot of money....

Choose your words

The headline in the Austin American Statesman:

Bush says Iran Still a Threat

The headline in the New York Times:

Bush Insists Iran Remains a Threat Despite Arms Data

Set aside political debate. Just consider how each of these headlines predisposes the reader while purporting to summarize the same event.

Marketing is about persuasion, hopefully more so than news outlets (!). How can you predispose your readers? How can you load the debate before it begins?

Every word in your headline counts. Use it to frame the debate before you potential customer even sees the competition.

I Will Survive

We make a peer code review tool for $400/person. What would happen if, today, Google released a peer code review tool? For free. And it's technically good, because it's Google. And because Google has tremendous visibility, everyone who's at all interested in code review goes out and tries it out. And it's open-source, so a community will be built around it and will add cool new features and plug-ins.

For free. From Google.

That's it for Smart Bear, right? No way we can keep charging for Code Collaborator, right? At least not at these prices.

I don't think so. Subversion is awesome and free and has a community, but Perforce charges $850/seat and their customers love them. Bugzilla is awesome and free and has a community, but JIRA, OnTime, Fogbugz, and TeamTrack have thousands of customers and continue to grow.

So how do you compete? You have to realize that it's not about selling software, it's about solving pain. No one sits around saying "What we need around here is another software tool!" No, even software developers themselves hate the idea of installing and learning a new application.

Here’s a hint: Imagine you have 100 developers under you and are charged with reducing bugs released to QA by 50%. Sounds fairly impossible (although our customers have seen these kinds of numbers). But how the hell do you do that without pissing off the developers or wasting time?

Your biggest concern isn’t whether tool A or B has the best diff viewer. It’s probably not even whether your initial tool cost is $0 or $30k. That’s nothing compared to the time, effort, training, and risk you’re taking on by doing any kind of peer review process. Not to mention your own reputation, and possibly your job.

The main blockade to code review isn't the tool -- it's the social change, the process change, the idea that someone else will be criticizing your code, the fear that pointy-haired bosses will be able to measure your "productivity" in terms of lines-of-code-changed and defect-density.

At Smart Bear we are experts in constructing practical code review, part of which involves a tool. All you can expect from a tool is to remove some drudgery -- integration with other systems means fewer mouse-clicks, organizing conversations and displaying them visually with the code is useful, collecting time-spent-in-review automatically so managers get their metrics but developers don't have to mess with stop-watches.

But if you're not good at reviewing code, it's still all a waste of time. Maybe you're bad at reviewing certain types of code? Maybe you'd get the most bang for your buck by reviewing just the code modules (where a little bug is a big deal) and not in GUI code under active development. Maybe some of these metrics are not actually correlated with anything, so you'll be chasing ghosts and making incorrect decisions if you look at them.

These are things everyone also worries about, and just installing a tool isn't going to fix it. But we can.

We give you a 164-page book for free that helps you make the right choices. There are articles and white papers on-line, for free.

And most importantly, you can call and we’ll talk about anything you want, for as long as you want. For free. That’s something no on-line forum or answer-by-Google-search can match.

So in light of all this, as the manager, will you go with the free Google tool with no assistance, no help, or do you want the direct phone line to the guy who literally wrote the book on how to construct truly effective code review processes?

How to be the most expensive product on the market

Seth posted a short, great article about how to completely win your space. It totally transformed the way I think about marketing. It's just a few paragraphs -- go read it and meet me back here.

A shallow interpretation of Seth’s point is that "service makes the difference," but that just leads to the usual phrases that have been repeated so many times they’ve lost meaning. "We put customers first." "Except the best, both before and after the sale." "We believe our role is to serve our customers." "Our customers are buying a solution, not a technology."

Blah blah. Everyone says that. What does it really mean?

Let's take that last vapid statement and make it concrete. It's true that no one wakes up in the morning and says, "Gee, I wish I could purchase, install, learn, and train my people on a new software tool!" Tools suck – they're confusing, they rarely do exactly what you want, and tech support is often a nightmare.

In our case, our customers have one of several specific problems that they'd like to make go away. Perhaps they spend 20% of their time in code review on boring, wasteful chores like collecting and sending diffs around or scheduling meetings. If it's something this specific, perhaps the tool can sell itself –- if it clearly removes the drudgery and during the trial the developers feel it saves more time than it wastes with its own idiosyncrasies, then it's worth it.

But usually our customers are in a more difficult spot. They need to reduce bugs or work with offshore teams, so they know code review is necessary. But how to do it?

This question -– how to do it -– is what keeps them up at night. They know they could easily blow 30% of their developers' time on this process. What if it doesn't result in reducing bugs? What if their developers hate it so much they revolt? How can they tell whether it's really working?

In fact, most people rightly believe the hardest thing about code review isn't the process, isn't metrics, isn’t reports, isn’t communication –- it's about (a) how do we make sure we're not wasting time and (b) how do we deal with social effects of ego-full, sensitive geeks critiquing each others' work?

This is where your "customer service" comes in. At this point it's not about tech support, it's not about what features your tool has, and it’s not how good your salesguy is at "closing."

I often sit down with a customer for a few hours. I help them as them the right questions of themselves. I help them determine which code they'll get the most bang-for-the-buck on so they can see some immediate results. I give them stories and even presentations about how gratifying code review can actually be, how to foster an environment where code review is genuinely about mentoring, learning, and getting rid of bugs together.

No tool will do that, and I also think no on-line form, Wikipedia page, or case study will do that either. Yes, our tool is important in removing drudgery and making reports, but it’s a means to an end.

The interesting part is all this mentoring stuff we do completely for free. If you tried to objectively quantify the true value to our customers of this advice and direction next to the tool, the advice is probably more valuable.

Maybe that's why it's the reason we consistently win over all other tools in the market. Because we're the only ones that can provide that service, and we do it for free. It tangibly demonstrates that we really do want our customers to succeed, not just buy some seats.

And of course when they do succeed, why go purchase something else? The free advice alone is worth any price difference.

How to build a checklist

CM Crossroads just published my article on how to build code review checklists. Half of which is, how not to build one.

It's not about in-scope/out-scope

The software project is behind schedule. The deadline is looming and everything finally acknowledges -- too late -- that we have to start making concessions.

So there are two choices, right? Release later, or reduce scope by throwing out features.

Not so fast.

"Remove from Scope" is not the answer
Too often we developers are stuck on this "remove it from scope" mantra. Yes, completely throwing out features is a way to get to the release date, but this isn't necessarily the best thing for the product or the customers.

Ultimately our job as engineers and not just worker-bees is to make trade-offs. Not just in design or algorithms, but in the end user use-case and, yes, even to support marketing and sales with their promises and messages.

Not cutting, but changing
Five years ago I was on a project with an impossible deadline. We had to get a complete custom reporting system integrated into a project for their v3.0 release, and for uninteresting reasons we had just four months to do it. There was a spec that couldn't possibly be completed in time, but the deadline was firm because a customer contract was in place.

The project ended up a complete success. The system was demonstrated to the customer on time and was accepted. It was so popular, it became the "big finale" for product demos.

The reason it was a success is because we never posed the question: "What parts of the spec do you want to throw out?" Instead we would ask: "How can we allow the user to accomplish what the original spec wanted him to accomplish, but in a different, simpler way?"

Sure that means less "stuff" -- fewer absolute number of features and fewer choices. But it doesn't mean tossing items J-M -- it means reevaluating the entire spec from the point of view of the use-cases and marketing requirements.

Happy days
There's another benefit to this approach.

We're all used to the tension between development and sales. Sales wants more, faster. Requirements pushed from the outside are ambiguous, and when you deliver it's never the right thing.

The normal reaction from development is: "You're changing the rules, therefore we simply refuse to give in. Either stop changing the spec or change the deadline. It's a zero-sum game, and we won't be responsible if you make the sum larger."

But that's not helping sales OR the hapless customer. (Customers don't have hap, apparently.)

What helps is arriving at a better solution. The project drivers will be more willing to negotiate if you're going to meet them halfway. They know they've added to your schedule. If you show the genuine desire to get their root problems solved, they'll be more willing to bend on exactly how you're going to solve their problems.

Besides, we can all agree that "Customer Success" is the ultimate goal, and clearly negotiating for their success is better than cutting them off.

Software is NOT like 6-Sigma

Six-Sigma, ISO 9001, and the like are processes used in mass-production lines to ensure vanishingly small errors.

It makes sense, if you're Dunkin Doughnuts producing 350,000 doughnuts per day. The problem is that some people insist that these processes should be applicable to software development.

"Why can't software development be more like electronics development?" "Six-Sigma means almost zero defects on massive scales, so why can't we use these techniques in software?" These are the kinds of questions you get.

And of course some people actually try. Defense contractors, CMMI devotees, and behemoth government-like organizations try.

But software development isn't like making 350,000 doughnuts. With doughnuts the thing you're making is completely understood and measurable, and the problems come in copying the Platonic form zillions of times without error. Difficult, I agree.

But in software you're making ONE, massive, complex, changing, ill-understood thing, and making it ONCE. When we ship copies, they are perfect copies. Unless you're burning DVD's, in which case the act of burning might be best handled under Six-Sigma.

The problems are completely different.

For example, our software interfaces with other tools. When those tool vendors release new versions, it's possible that they break our interface with them. Therefore, even with perfect copying and no existing bugs, our software will STILL BREAK!

For example, in software requirements are supposed to change. Possibly during development, definitely afterwards. Once it's decided that a bridge is supposed to go from A to B, it's done. Even if that decision turns out to be wrong, everyone accepts that either we should nuke the bridge or finish it anyway -- there's no concept that we should rebuild the bridge in mid-air and still make schedule. Not so in software -- this happens all the time.

For example, software's purpose changes over time. A doughnut is always supposed to be a doughnut. A home Wifi router gets small firmware updates, but no one expects it to do more than what it did on the they day bought it. Most software projects change radically over their lifecycle. Windows 1.0 barely solved any problems; Windows 95 changed everything, and Vista barely looks like it came from the same company that released XP. Even Google Search -- the algorithms, advertising, and company goals are nothing like they were when it first became well known. But Dunkin still primarily makes doughnuts (and coffee), and we expect nothing now from 50-year-old bridges than what we originally expected.

There's more. Software developers themselves are a different breed than workers on the doughnut assembly line floor. The world-view and skills required for software development turns over at least every 10 years (more often if you want to change jobs). And sometimes a new feature really is more useful to a customer than a bug-fix, though rarely does anyone admit it.

The point isn't to say that it's OK that we have bugs in software, or that we can't do anything about, or that we shouldn't try. It's just that blindly applying process from other disciplines is not the answer.

Bing! You've got Cash!

The worst ATM I've used is at the Austin airport.

That in itself is a weird statement. How different can (should?) an ATM be? Just give me cash fast, right?

First it asks what language I want. Fine.

Then it confirmed: "You have selected English. Is this correct?" Yes.

But choosing "Yes" made a sound that is exactly the Windows "Cannot click there" sound. Like when you click outside a modal dialog. Turns out it used that sound every time you selected something properly, and no sound if you made a mistake -- precisely the opposite of my Pavlovian reaction. The whole experience was unnerving.

So then it asks whether I want "Fast Cash" or "Other Transactions." I chose fast. I got the usual list of $20, $40, ..., $100. But I needed $150 or $200. Not an option. No way to say "Enter a number." Only other option is "Cancel." So I hit "Cancel."

Not so fast! Now I am prompted: Do I want to "Exit" or "Start Over." Start over of course. Oh wait, you need to swipe your card again and select your language. So "Exit" and "Start Over" do exactly the same thing. Great.

This time it's "Other Transactions." The following screen was identical to the "Fast Cash" screen, except now there's also an option to type a different amount of cash.

Sigh.

Does your application have more choices than it needs? Does your application ask questions it doesn't need to?

Sometimes it's more subtle. For example, maybe you have 10 independent user settings, but there are really just 3 combinations of those 10 which 90% of users really need. Why not provide one option with 3 choices instead of making the user figure that out?

Or take a middle road: Provide 3 choices, but also have an expandable "Advanced" or "Details" view where power users can tweak further.

Not only will this cut down on your tech support, it also helps new users get going in the system with something consistent and sensible for them, which means your trials might go more smoothly.

So now that you've reached the end of this blog entry, would you like to Exit, or Start Over?

December Dumbass

Don't be a schmuck.

This is Jackie Mason's advice about financial investments. Or how to buy a suit. Or how to treat your mother. I think it's his advice about everything.

He's right. Especially about software release dates.

In my infinite wisdom, last year I decided we needed to release Code Collaborator v2.0 at "the end of the year." This was brilliant because: Since everyone is on vacation at the end of the year, the office will be relatively quiet and we can get the release done.

What I didn't consider was that we would be on vacation too. And that the customers who we imagined were anxiously awaiting our release were also on vacation.

So after killing ourselves, and slipping to Jan 20 anyway, turned out no one cared. We cared about our deadlines much more than anyone else.

Even when you have people waiting for a release, remember that they'll upgrade when it makes sense for them. If you're in the middle of a release cycle, you probably won't spend the time, take the risk, and get retrained on an upgrade. We're the same way -- a new version of the profiler we use came out during our 2.0 crunch, but there's no way we had the time to mess with it then. Even if it's better.

So this time we released v4.0 beta on Oct 1, and we expect to exit beta before the end of the year. But if we don't, we don't care!

800lb Gorrillas Don't Care

NetFlix just posted their first ever decline in subscribers. They attributed this to Blockbuster -- the company some people thought they would put out of business.

A year ago Blockbuster responded to NetFlix's success with a similar program of their own, except that you could trade in DVD's at the store which meant more immediate turn-around time. It's a great way to leverage their advantage -- physical stores -- against a seemingly unstoppable business model.

And it worked. Or did it? Blockbuster reported an $82 million loss for the first half of 2007, attributing this to costs associated with the new plan. So they slowed NetFlix, but it's hardly a success.

Small business operators worry about this sort of thing, especially when evaluating ideas for new ventures. What if the 800lb gorrilla wakes up and decides to compete with you? They have zillions of dollars to throw at it, and they probably don't even have to make a profit. How can anyone compete with that?

Stop worrying. In my opinion, this should never enter your mind, and here's why:

First, I'm assuming that you have your own niche, your own market, your own game. Something no one else -- certainly no one with a large, established business -- is doing. You're not going to go head-to-head with them out of the gate.

So assuming you're skirting the big guys, your worry is that they'll notice your activities and squash you.

First of all, your market ought to be so small that a big company wouldn't care. Even a $500 million market is too small for a mega-corporation to attack -- even owning 50% of it wouldn't account for the amount it would cost to own it. As much as you might think this is personal, it isn't. They don't care about squashing you, they just want to make more money.

If you do grow to such a size that you've validated this (new?) market, perhaps proving it's better than anticipated or that there's buzz to be had or whatever, to the point where the Goliath is willing to spend 100's of 1,000,000's of $$, you've already won. You're already wildly successful, more than you ever thought possible.

So don't worry. The elephant won't swat the fly. They don't get it, and that's in your favor!

Do the right thing

Plane had a tear in baggage compartment. Rather than make SOME bags late for SOME people, putting on the next flight, EVERYONE was 3 hours late.

Hope the bags make it...

Make sure you don't treat YOUR customers this way.

I've got nothing

The final six hours was great. This is definitely the best I've felt all week. Some of it is sinking in, although I'm not sure anyone else would find our scenes worth watching yet.

We played a game called "1, 2 Selected." This was invented by some guy at a convention; our teacher liked it so much he decided to show it to everyone he knows with the hope that eventually it gets back around to the same guy. Then that guy can say "Hey, that's my game! I invented it!" And probably no one will believe him....

Anyway, the game starts like this. One person on stage with a partner starts a beat by snapping; everyone joins in and keeps the beat steady. Then in time with the beat (drawn here with the pipe symbol) the person chants "|Who|Ha|1,2|selected." The partner then calls out either "1" or "2" immediately (well before the next beat). Now if the partner called out "1" the person repeats the same chant, otherwise it's repeated with "|Ha|Who|1,2|selected." So the "1" or "2" response controls the order of the first two words. But you're on a beat so the calling-out of the number has to turn into one or the other very quickly.

So at first even this is hard, but then you get to where you're really concentrating on what the partner says, and you can get it pretty smooth. Fine, but that's just the warm-up. :-)

The real game is: Now instead of the choices being "1 and 2" you have to come up with a pair of words on the spot. They can be anything, "dog,cat" or "floor,can" or even "dog,shog" -- it doesn't even have to be real words! Then the second person repeats one or the other word (so not "1" or "2" anymore) and the same "|who|ha" or "|ha|who" rule applies. And every go-round you must use different words.

This is really hard. The point is to get you listening and reacting while also loosen your brain so words will just flow out. Of course they typically do not flow out. Also there's the tongue-twister aspect of the who/ha stuff.

The first stage exercise was "Worst Scene Ever." You get up there and intentionally break every rule you know. Lots of possibilities here -- stand with your back to the audience, walk through the made-up table, call the person next to you "son" and then "dad." Jokingly the idea was to "get all that out of your system," but it was also useful as a warm-up because it makes you re-think the rules which does make them stronger in a way.

The second stage exercise we did is called "The Double-mint Twins get Fucked up the Ass." Four people get on stage in two pairs; each pair stands right next to each other. You do a scene, but the rule is that each pair must talk, move, etc. together and simultaneously only. Of course you cannot talk beforehand to decide what to do, so you have to just detect who is leading and where they're going. You also move and talk in very slow motion so the other person can detect and catch up to what you're doing. It's bizarre. What you're practicing is paying detailed attention to what the other person is doing and detecting who is trying to lead.

The scenes we did this way were actually pretty funny. I think it's because with the slow-motion you have lots of time to think about the next line. Also two people are thinking about the next line; if one is dry maybe the other has something.

Another exercise we did called "Monkey Wrench" was designed to get you to think fast and to accept whatever happens in the stage environment. Two people start a scene and establish who they are, relationship, etc.. Once it's comfy, a third person (the "monkey wrench") from the wings comes out and completely violates the world -- breaks the Rule of Agreement -- and walks off. For example, if the two people are mopping the floor of a hospital, shooting the bull, the monkey wrench could swim in front of them. The instinct is to "drop your shit" -- lose your character and suddenly be bobbing up and down in the water. Wrong. That just happened, and in improv no matter what you thought the assumptions were you have to deal with whatever is happening on stage without violating anything else you've established. So in this case you just have to accept that you're two janitors cleaning the bottom of the hospital's pool. So you might start by saying "The bubbles from these scuba suits make it hard to see when the floor's clean." "Yeah, but with these new suction-cup-boots it's a lot easier to clean!"

Of course the scene doesn't have to be completely plausible after that, nor does it have to be funny. You're just practicing "dealing with whatever" and not dropping what you've got. In a real performance no one else would violate your space that badly.

The interesting thing there is that often the result is very funny. In fact, just the act of accepting it and even making stuff up about how this makes sense anyway is in itself funny. Plus, as the teacher put it, the audience enjoys it when something awkward happens, and enjoys you getting out of it or explaining it.

The next exercise was called "You and I." Two people up, and the rule is: Every line must start with "You..." So e.g. "You always do that to me." "You think it's OK to kick old people?" "You don't know this about me, but." Both people do this. The point is that even with this restriction you can actually learn quite a bit about the person talking, even when the content is always starting with the other person as the subject. Then there's the same but starting with "I," and you see the opposite -- that even just talking about yourself you can still imbue the other person with all sorts of attributes and history.

The lesson from this point is that you can tell these stories in less direct ways. If you want your character to feel doesn't get enough attention, you don't have to just say "You never pay attention to me." Instead you can beat around the bush -- and in fact this can be funnier, can work better into a scene that might not ultimately be about that, and even in real life this is usually how these feelings come about anyway, so this indirectness can be funnier because it hits closer to home or is more plausible.

We continued this idea in a more difficult way in the next exercise. Three people got up and the whole situation was given to them. First, they all hate each other, and we would give 3 or 4 reasons why each would hate each other. Tons of reasons. Cheating with women, killing their baby, running over their dog, lying so the other person had to go to jail, etc etc. Pile on the hate. Then situation of the scene is such that they have to get along. Maybe they're all groomsmen at a mutual friend's wedding, and they're backstage, so they can't break out a fistfight. They have to find common ground. They might bring up something from the past, they might fling a fleeting word, but they have to get through this together.

It's difficult, but the lesson is that not all scenes have to be "The day the shit went down." Beginners have a tendency to do these types of scenes: Couples breaking up, a kid doesn't want to go to school, someone wants to quit a job, whatever. And some of this is because of rules and exercises we were given -- remember the one about moving a scene by saying "I have a confession to make?" Those are "The day the shit went down" because something big is happening. It's sort of the obvious way to make a scene "go somewhere."

But the other type of scene is "Slice of life." A J.D. Salinger-style snippet. These scenes are the most common with pro's for several reasons, but mainly because that's more usual and reasonable. People do have back-stories, possibly even sordid, but almost all of real like are people interacting without the "big event" going down. And then you can see characters more subtly, and that's probably more funny.

But these are really hard for beginners because you don't know where to take them, how to develop them. And you'd better have a strong sense of your character because it's going to be about the character far more than putting it in a stressful situation. So this exercise got us to at least think about that and try it.

Finally, we got a little practice at the "long form," meaning multiple scenes strung together as for a real show. It includes edits (other members deciding when the scene should be "cut" for maximum effect, described elsewhere). It often includes call-backs where a character from a previous scene makes another appearance. There are some tips for that; for example, whatever trait that character has must be immediately apparent when you call it back so all the players -- and the audience -- immediately understands who it is and not some new character.

The best advice I got today was: When you're sitting on the sidelines, sometimes you have some ideas. Ideas for character traits, desires, motivations, a funny situation, whatever. OK, but sometimes you really have nothing -- you're blank. At that moment, walk on stage. Do not hesitate, do not say to yourself, "Oh, I need to think of something," just walk out.

Of course this sounds like suicide. The odd thing is it isn't, and it's almost the opposite. I don't know why. Maybe because once you start thinking you're already lost, maybe because doubt leads to fear, maybe because clean slate + jolt forces you use all these on-the-fly techniques we've been taught rather than relying on something you just ruminated over. Whatever the reason, today I jumped up on stage every time I felt that way, and it always worked out well.

So this was the end of the course. It was a blast and I'm going to continue with classes although not in this intensive format. I've already felt this experience changing some aspects of life outside the classroom; I'll be thinking about that and will take some time to digest it before writing about it, unlike these entries which were just brain-dump journal entries from my class notes.

Where have your fingers been?

What do these things have in common: Screaming, the living room, dirty fingers, and a convenience store? All improv games, of course!

Day 5 started with a "Convenience Store" game, but different from the one described a few posts ago (which was about object work). This one is character work -- from a circle, one person approaches another, having to develop a character in the few steps on the way there. (Extending the notion I wrote about before of using whatever you just did and how you feel to build it up immediately.) The person you approached is the convenience store clerk, standing behind the counter. Your character has to ask for three items and pay for them; of course the way you ask and the things you pick and so on should match the character. When that's complete the clerk heads off to be the next character. In the interest of time we started three of these at the same time so everyone's engaged most of the time.

Then we started right into the arbitrary scenes. Before you went on, you had to think of someone you know and be that person in the scene. Imitate them, exaggerate a characteristic, have their motivations. Of course where you're up there it's not vital that your imitation be accurate -- you're just using this to inform the character and it's OK however it turns out. This was a great exercise for me because for some reason it clicked. It made it much easier to know what to do, how to react. And in each case I ended up not actually being that person, sometimes not even close, but having thought about that and coming out with something a specific character did develop and it was easy to work inside that framework.

We did more scenes with tips that echoed that from previous days, so I don't have to go into detail. Things like: "Come out with an adverb" (decide you'll be happy or fast or angry). And: "One thing that drives you" (You want to quit your job, you want to get the other person to appreciate you). Again, sometimes the scene does become about that, sometimes not. But having that makes something happen, and when everyone on stage sees the something you can then work with it. It helps to generate something real and plausible; otherwise you come out with nothing and have you work out what's happening during the scene -- not only is that hard, it's actually bad for the audience because if you don't know what's happening, the audience certainly doesn't know, and that's not entertaining or funny.

Another great tip was: "Deal with the 1st weird thing that happens." Weird things are a "gift." If two people come one and one trips on the way, that's probably the whole point of the scene -- this guy trips all the time. If the two personalities are a weird mix -- which usually they are -- then the point of the scene and the comedy is exploring the idea that this weird mixture is in fact normal. These two characters don't match and yet are friends or doing a common task or whatever. That in itself is a great source of comedy. So whatever it is that's "weird," right at first, grab that and instead of figuring a way around it (i.e. to make the scene more plausible), build that into your assumptions. On the next day we actually did more exercises about this, but more on that in the next post.

After the break we did a "Screaming Exercise." Everyone gets into a rugby scrum, looking down. Then on the count of three you look up and at someone -- anyone. Make eye contact (most of these exercises involve making eye contact). If the person you're looking at is also looking at you, scream. That's it! It's weird and funny. Just loosens you up -- I'm not sure there was an important lesson here.

Then we played "Where have your fingers been?" In a circle you sing a little song asking where your fingers have been, then the first person turns to his left and names a non-geographical place/situation, e.g. a picnic, the south pole, an assembly line, dinnertime. That person then has to play out a little 30-60 second scene using two fingers to represent two people. The purpose of the exercise is obvious. It's easier than a real scene because you're in control of both characters, but you still have to think quickly and develop some situation.

The most difficult exercise of the night was "The Gauntlet." This is essentially the same thing as "10 characters in 60 seconds" from yesterday, except that in this case there's another person on stage. That person only reacts however -- no help in trying to complete the task. But as it turns out this is (slightly) easier than just doing characters on your own because the other person gives you ideas. It's not on purpose, but e.g. if you see someone laying down than maybe you're giving them CPR. It's slightly easier to move into a situation where anything else is present. Still a very difficult exercise but this made more sense to me than the one where you were just up on your own.

Finally we did "The Living Room." This is a show format, meaning a structure that could be used to fuel an entire show rather than just one scene. It's essentially an idea-generator for scenes. The players are on one side of the stage (the "living room") and then talk about anything just as they are -- no characters here. Whenever something is said that gives you some inspiration, you just jump up and start a scene. Someone else jumps up too. Normally in this format you self-edit -- you decide when the scene is over. It was kinda fun to do it, but it didn't add any new information or skills other than just being more practice.

Tomorrow's the last day!

I am a tree

Day 4 was about character building. Not making you a better person, just helping you act like some other person. There were fewer different lessons but we spent more time on each one.

In the first exercise we stood in the back of the stage. The teacher would call out a name and you had to go out there and start talking immediately. No waiting until you're somewhere, just start going, no thinking. The point was that you have to work out who you are as you're talking and walking out there. Whatever you happen to say, do, any noise you make, it has to become the character -- in fact it drives who the character is. The scene lasts only 30 seconds; you're just trying to arrive at the meat of the character as fast as possible.

As another exercise to start thinking about characters, we started in a circle. We remembered who was to our left and right. Then, back on stage, the teacher would say "imitate the person to your left." In all scenes you do, you have to imitate that (real life) person. Even though we don't know each other, still mimic them. Then the person to your right. Of course you're also watching as people imitate you.

Then think about how other person imitated you. What did they stress? Now take those attributes and multiply them by 10. Now do scenes as "exaggerated yourself."

The point of all this? If you're stuck needing a character, imitate someone you know. Or just exaggerate something you are naturally. These are all places to get ideas from.

Then we did another warm-up exercise called "I am a Tree." Someone stands in the middle of the circle, puts out arms like branches, and says "I am a tree." Then you think of something relating to that, say you're that thing, and get into position. So "I am a left" and go over to a branch. "I am the buried dead body" and lay down next to it. "I am a squirrel." Once you have 3-4 things, the first person says "I'll take everything but the dead body." Then everyone except the named object leaves the center and rejoins the circle. The remaining person repeat who he is ("I am a buried dead body") and you continue.

The next exercise was an interesting exploration of what it means to build a character. First everyone generated a multi-syllabic word. (We did that with a word-association game in a circle.) Mine was "fast cars," another was "rhinoplasty." Then each of us took turns doing the following. One person gets up on stage alone and starts repeating the phrase. Over and over. Say it different ways. Break it up, misspeak it, emphasize different parts of it. Like when you're a kid and you say a word so much it loses meaning. Then some syllable will stand out as being the "most prominent." Focus on that one. Play a little more until you've got some way of saying it that you just like. Then keep repeating it exactly that way, over and over, meaning lost.

Here's where the character comes in. Who would say the word like that? Who would say everything like that? Why? Where does this person come from? What's this person's name? Gender? What does this person do for a living? You don't get too long to think about it -- because then people start asking you exactly these questions and you start answering them. How old are you? What do you do for fun? What do you think about the upcoming election? You have to think of it, but you have in your mind who this person is. It's surprisingly easy to come up with fairly detailed answers.

And that's the point. If you can flesh out a character, you know how he will react to any situation. What he thinks about it. What drives him to do things. Of course on the improv stage you don't get this much time to work it out, but this is what you're striving for.

The hardest thing we did was "10 Characters in 60 Seconds." One person on stage, teacher with the timer. Ready, set, go! Build the entire character in 6 seconds, then the teacher yells "switch" and off to the next. The first few aren't hard because you're used to a few characters, but soon you run out of ideas. The time-pressure is on and with just 6 seconds you have no time to think -- you just have to start talking.

The trick is to just do something. Make a noise -- any noise. A shriek can turn into a scared camper. A stomp can turn into an angry teen. A weird hand motion can turn into a guy with Tourette's hailing a cab. Falling to your knees can be someone proposing. Just do anything ("put a stake in the ground") and start rolling with it.

Even knowing the trick, this is really really hard.

The final character exercise was a two-person scene where each person is given three random character traits, but the trick is you cannot ever refer to these traits in the scene. So you're carrying them with you, using them to affect your world view, your actions, etc., but you cannot use them for topics of conversation or even mention them in passing.

The point here is two-fold. First, this is a lot like real life interactions. People have various experiences in their history which has helped shape how they interact and what they do and think. But they don't bring everything up in conversation! Besides just emphasizing that, the second point is that in improv you can give yourself these hidden attributes. When you walk on stage you can already have little things in your past. You don't ever have to talk about it -- you don't want to force the scene -- you can just use it to help shape and understand your character. Don't bring up how your character was traumatized by snakes as a kid, just be traumatized by something, or approach everything gingerly because you have been traumatized.

Once again, all is easier said than done. It's hard to come up with "random" yet coherent things.
Finally we got some more tips on 3-person scenes. One was that you can think about them as 3 2-person scenes, each character having a certain and different relationship to the others. The example was your grandparents. They have a certain relationship to each other much different than the one with you. And you have a slightly different relationship with each of them -- it's not automatically the same for both just because they're both "grandparents."

Our next class is at the Hideout, and after class there are two 30-minute shows upstairs. It will be really interesting to see pro improv again after having this behind-the-scenes look. (Oh, I guess that was a pun)

Lead with your neck

It's finally starting to click on this day 3! Yesterday felt like sliding backwards but tonight it worked. Started internalizing the rules, relaxing in the parts, scenes that made sense and were even funny. Fun!

Tonight's warm-up was an "invitation game." Someone in the circle does something random to the person to their left. Has to include some sound/words (e.g. "Hellloooooo" or "Figgy Pudding") as well as distinctive movement (e.g. a sweeping bow or jumping from side to side). The next person turns to her left and attempts to repeat everything exactly to the next person -- sound, movement, facial movements. And so on. But fast. And you're not trying to imitate the first person, just the previous person. So of course it morphs as it zooms around the circle.

The point is to get you to pay attention to what just happened close enough to repeat all parts of it. Also -- as with all warm-ups -- the point is to get silly and get rid of the filters and normal rules of behavior and interaction. Silly or, as the teacher put it, "Be gayballs."

The first lesson reinforced the idea that what happens at the very start of the scene must be sufficient fodder for the rest of the scene. The game is "Three-Line Scenes." You only get three lines total -- player A, then B, then A and you're done. The trick is that at the end of the scene you have to know who both of you are, and your relationship to one another. What it is you're doing isn't important.

It's challenging to bring that much information in just a few sentences, but it hones your ability to get to the point of the scene very quickly. When you don't know who you are or why you're there or your relation to the other person, you're fishing. You're throwing things out and seeing if anything sticks. By the time something does (if ever) you've invented so many different things and now you have to deal with all of it and make sense of it.

So the first benefit of the quick-to-the-relationship is to establish what's going on. The second is that you've established everything important you need for the rest of the scene. Of course you develop things, heighten things, change something to develop the plot, etc., but if you know what's going on it's not so much of a struggle. You've defined the boundaries of the world and now you follow it. (Although it turns out it can be more difficult than it sounds to understand the implications of the world you just created...)

In the "Three-Line Scenes" exercise you emphasize this by stopping the two players and asking each things like "Who are you?" "Who is that -- your brother, friend, roommate, what?" If there can be more than one answer to too many of those questions, you haven't done your job.

Another thing we covered in a minor way was "edits." This is where the players in the wings decide when the current scene should be over. Up until now the teacher "conducted" when we started and stopped. The skill here is in picking the time to end the scene. If a scene is progressing nicely (which ours still aren't, usually), it will "heighten" (more lingo) towards a climax. You don't want the scene to get past the climax. There's no denouement in improv -- you want to cut it off just as it couldn't get better.

The rule is: It's better to cut off early than late. If it's late it's called "cooking" the players on stage; you're hanging them out to dry. Ideally there's some great "out line" -- the final nail in the coffin, the note to end on. The problem is you can't count on that in the scene because if you do that on purpose and no one comes out and edits you off the stage, there's not a good come-back.

Doing the edit isn't anything special. The editor just walks confidently across the front of the stage from one end to the other like a curtain being drawn. Has to be strong, fast, and confident so it's obviously the edit and not e.g. another character coming into the scene. Also the editor starts the next scene immediately. Some people say you can jog across the stage for this, but our teacher pointed out that it can look cheesy.

We did an interesting exercise to get a feel for when the edit is right. The game is "Cocktail party." Everyone's on stage in pairs and each pair gets a topic of conversation. Everyone thinks of a separate character and pretends to converse with the other in the pair. The teacher points to one pair who starts talking about their topic. Then the teacher cuts them off and points to another pair, and so on. When it comes back to you, it's the same characters but "10 minutes later" in the conversation.

Then we have to decide when to cut off each other. You let a pair go, then when you think it's time (30-90 seconds) you start in on your deal. There's a few lessons here: Deciding when to cut off, and jumping in without cutting off someone else who just beat you to it; communicating about that sort of thing without words or gestures.

There was a lot more talk about the steps of "establish, then heighten." Nothing deep to note here. "Heightening" means bringing the scene along, digging into the world that was established (hopefully in about 3 lines). Let's say player A is a great bowler and player B isn't, but since they both started bowling at the same time, B is envious. So the key here is: B is envious of A. So envious of bowling, what else? Maybe B could say, "So what did Tracy say about your medal at the Iowa State Finals?" A can take that and run; now B can be envious of that. What else? So it's not really about bowling, it's about envy -- dig into that. Also at the same time maybe they're roommates and they're moving. Moving the bowling trophies, which brought it up. But don't talk about moving because then you're just saying boring stuff like "Can you hand me the glasses?" (snore) or "What do you think of the new place?" (who cares? it's not relevant, and now we have to invent a bunch of stuff about this other place and why we're going there etc. etc.). What's going to be funny is how pathetic we can end up making B and how awesome A is.

There's also another term called "giving a gift." It's not exactly prompting the other person, but it's setting up something that's easy to work with. Not necessarily directed, but a little thing in the world that's easy to play inside. For example, "This is just part of my brick collection." This is a little nugget. Who the hell has a brick collection? Is this a hermit, loving his bricks? Does he use it to get attention? A guy who collects bricks might have other weird hobbies. Or maybe he likes nothing but bricks. And what about the other player? You could approach this guy in all kinds of ways. Make fun of him. Congratulate him. Compare your own brick collection to his. Or argue that ant farming is more interesting.

This is a gift. It leaves lots of options for both players, but it's not so vague that nothing is established and we're not sure what to do next. Of course it helps if it's funny, but that's not at all necessary.

Another exercise helped to clarify how to think about two characters with a backstory (even though you don't know the backstory yet). You start a scene; this time you're given the situation (e.g. "Pimp and whore," "President and bodyguard"). You do a little with it, establishing the relationship. Remember, the situation is not the relationship. Maybe the president has control issues about how to work the move from one room to another, but the bodyguard has ideas of his own. Then control-freak vs. the expert is the relationship. Then the teacher calls out "20 years from now." Now continue with the relationship and characters 20 years into the future. Not the same lines, not the same situation, but the same relationship. Then "5 years before the first scene." Then maybe "1 day before that." And so on. It crystallizes the importance of the relationship over the situation. Also it helped me think more about the character, and it demonstrated (again, but we need the reinforcement!) that knowing the character and relationship is all you need.

Another interesting sub-rule there is "Start in the middle." It's tempting (when you suck like we all do) to get on stage and say, "Sooooo, hi I'm Jake." This is starting a fresh relationship, and it's bad because: It's hard enough to create a world from scratch -- by creating a world where these two characters don't know each other, you now have to build the relationship during the scene. And the relationship is the scene. So it's a lot harder.

So whenever we'd do this the teacher would say "Freeze," then instruct to keep everything the same, just fast-forward 10 minutes. The time-shift exercise also pointed this out in a more general way.

There were a variety of tips on how to get out of trouble. Show, don't tell. No stories, just do it in the moment. Have an honest, strong reaction to whatever's going on. Whatever your character might think, just say it out loud. Start with "I have a confession to make: XYZ." Or "You're making me feel XYZ." Or "I know you think I'm XYZ." Throw a stake in the ground. Make a strong choice.

Another interesting tip about how to get on stage with some concept for yourself but flexible enough to deal with any situation: "Give yourself an adverb." Don't think "I'm going to be the president" because that might not work out. But you can be "presidential." Decide that you'll conduct yourself that way no matter what happens. Gives you an anchor and something to build on. And it can almost always work. If it's dad/son scene, if the son ends up presidential and the dad is a goofball, that's probably funnier than the other way around!

The other real eye-opener tonight was in some character development exercises. The best was one where we'd start by all milling around the stage, walking around randomly, making eye contact with everyone. Just be yourself. Then the teacher calls out something like "Now lead with your knees." What does that mean to you? Of course everyone does something different. Maybe you high-step. Maybe you're wobbly. Maybe you're leading with one leg and dragging the other. So you just walk around in whatever way makes sense to you. The teacher is asking things like "Why would you walk like this? Are you old or young? Do you have a disease? What kinds of things would you eat? How would this person sound? What does this person do for a living? What's this person's name?" Then you start having to greet people as you walk around, in this character, in the voice, however this person would greet another person. Making eye contact the whole time, still milling around the room. Then finally you have to find someone and a topic of conversation is yelled out, e.g. "mutual funds." It's surprisingly easy to talk about whatever, because once you've really thought about who you are, you just respond through that filter.

Of course the idea is this is exactly what you're doing in an improv scene, except you get less time to think about who this person is. But you can come in at least with an adverb and some ideas, and as things are established (in the first 3 lines?) you should stick to whatever choices were made.

Finally we ventured into some 3-person scenes. Teacher warned that multi-person scenes are especially susceptible to becoming clusterfucks. (Wow, the Mozilla spell-checker doesn't know the word "clusterfuck." Hmmm, Add to Dictionary... Maybe I should add "gayballs" too...)

A common game used to keep it coherent is "2-on-1." It's just what it sounds like. The point is that if there are three different opinions OR if everyone agrees it's hard to go anywhere. I guess in a way this turns it back into 1-on-1. We were instructed to just do the 2-on-1 format since of course we're not good at 1-on-1's either. It actually went pretty well, especially for the "2" people because if one was stuck the other could jump in. And somehow it's funny when 2 people are defending a weird idea against one straight person, I guess because the 2 are automatically stronger and yet their pushing something weird.

The other general rule with multiples is "Keep it simple." Even more simple than usual. We did one scene where it was all 8 of us and the scenario was "basketball teams." I started the scene by jumping to the middle, doing some stupid movements, and yelling "Aww yeah, y'all got SERVED!" The other team looked sheepish. This set up the game of: "Our team is cool and makes fun of you and keeps congratulating ourselves, and your team is continually uncool and unable to come back." We kept it just at that level -- no development or anything -- and it was still hard to keep things together.

Anyway, tonight was the first time that I started feeling comfortable going out there with enough in mind that it isn't random, but still being able to react to whatever. So that felt good, and ended up in some coherent scenes and even some funny moments. The next few classes will start to get more into characters, common games to play and pick up on to make scenes work more easily, and see how rules can and should be bent.

Who are you to deny my space?

Day 2 of the class is through. I think I feel less sure about everything now than when I started. Too many rules to think about at once? The best scenes are 99% normal everyday material and you'd think doing "everyday situations" would be the easiest thing. But it's the opposite; somehow it's hard to be in a natural situation -- you have the urge to invent ridiculous objects and scenarios but then you're really stuck because you don't know at all how to deal with that.

So ironically the rules help keep you doing something realistic and natural. It's odd to need help with that.

We started out with more "7 Things." Our teacher this time really likes this game (described yesterday) because it not only frees up your thinking but also reinforces that everyone else "has your back." It's important in the scene to know that the other player is working with you. This games echoes this in that you yell "Yes!" to everything to affirm that it's accepted no matter what it is.

The other warm-up was new: A pattern game. One person starts by saying a word and pointing to another person in the circle. That person says a related word (where the "relation" is invented on the spot) and points to another person. The third person tries to pick up on the pattern and says another word and so on. (This isn't the person next to you -- you point at anyone else haphazardly around the circle.)

For example, say the first word is "New York." The next word might be "New Jersey." The third person might say "New Orleans" and the pattern is now obviously "things that start with 'New.'" Or the third person might say "Alabama" and the pattern is "states."

That's the easy part. You repeat the same words, in the same order, pointing to the next person, remembering who "sends" you the pattern and to whom you "send" it to next. Then a different pattern is started with a different order of who says it. Repeat that until it can go fast around the circle.

Now you start one pattern, but as it's going around you start the second at the same time. You have to stay on top of where the patterns are and when it's your turn and to whom you send this one. Then add a third pattern. Or two of one and one of a another.

The complication adds a new lesson: The best way to support this technique and not lose a thread is to make eye contact with the next target, hand off the pattern, and keep eye contact until you're sure that person has it. This concentration and visual communication is useful in the improv scenes as well. It's also probably a life-lesson about communication.

The next mini-lesson was that the first three lines of a scene should determine the scene. You should know who you are, where you are, your relationship, what you're doing, etc.. You do not need to know all of these things, but you need some kind of basis. The description of this was: When you step onto the stage the possibilities of what's happening are infinite. Then one person says "Dad, I'm not going to college." That reduces the possibilities down to, say, thousands. You know this is a kid, the kid is stating something that might not be obvious, the other person is the dad. The next person says "You're going to college, and that's final." Now the number of possibilities shrink to hundreds -- you know this is a challenging position, the dad doesn't agree. But maybe this conversation was had before? "But dad if I don't turn pro now I'll never get respect with my monkey act." Now you've got something.

Another little point that came out of a scene is that although it's fun and exciting to start a scene with a lot of energy, it's hard to maintain and after it's done it can be hard to decide what to do next. Examples are like "Hurry, they're coming they're coming!" or "Get them off me get them off me!" So you do get "them" off and everyone calms down.... and then what?

One of the biggest lessons of today was "every line counts." One scene started with a pizza guy showing up. The customer opens the door and says "Wow, that pizza really stinks." After a response the customer says "Wait, I think it's YOU that stinks!" Then it trailed off into random inventions since they didn't know what to do with the scene (as we all did when we got stuck, which was frequent). So the teacher points out: You, a customer of a pizza delivery, open the door, find a stranger, and basically the first thing you say is "Man, you really stink." That's not normal. So either (a) don't say something that doesn't make sense, or (b) that DOES make sense for that character, which means that character is the type who would immediately tell a stranger that he stinks. Now THAT's a good character, so stay with that. What else would he say? Would he say you're ugly, you suck at making pizza, your car is weak, what?

By latching onto and digging into what each person has set up, both now have something to work with.

There were a couple of new variations of the Rule of Agreement. The first is "Don't deny history." If something happens in a scene, you can't negate it later. Sounds obvious but in the moment it's easy to accidentally stomp a tacit assumption that another part of the scene created.

The other is that one space/props are built by miming you must respect and play in that space properly. If someone has built a table the other person can't walk through it. Or, if the other person does, you have to deal with having just knocked the table over!

Speaking of props, we dealt with that more today. All props are invented with miming. We had two games to get used to this idea. First we stood in a circle and balls were passed. "This is a blue ball" the first person would say, and show the ball with miming. Maybe the ball is the size of a speck of dust. Maybe it's heavy and has to be carried with two hands. Maybe it's bouncy. Maybe it's giant and has to be rolled on the ground. The point is you pass it to other people who have to maintain the characteristics of the ball. The trick is you get three of these being passed around at the same time. Also this helps with the communication/eye contact thing -- you lose balls if you can't pass them properly.

In the second we built a scene using just miming. The first was a convenience store. Everyone stood in a line outside the front door. The first person goes in and does something, like get a beer and pay for it. This establishes the beer area and the cash register and the exit door. Each successive person has to interact with each thing established by the person before, plus add a new thing, plus not break any established things like counters. You can move stuff, break things, etc.. Then we repeated that game where we also had to come up with the scenario as we went rather than being provided it. Sometimes you could talk, other times not even that.

It's amazing how much little things matter. If you half-mime something it's not convincing. If you really carefully act it out, it suddenly becomes real. If, then, someone else violates the space it's palpable. Human perception is weird like that.

Finally there were two main scene exercises. The first dealt with the problem of each person having preconceived notions of who they are. You're supposed to have this notion when you step on stage -- that's what gives your character weight and purpose and helps drive the action. On the other hand, what do you do with two random characters? How do you blend them? So the exercise is that each person is given a line to start with (whispered) and must start the scene with that line. Of course they don't match. You have to come together somehow.

The second was a way to get us to relax and talk more normally about something. Two chairs are placed next to each other and you sit. You're given a task (e.g. surgery, fishing, rowing) and something to talk about (e.g. golf, cooking, furry animals). The rule is you CANNOT talk about what you are doing, just on the subject. The odd thing is this makes the whole thing much easier. When you're not worried about discussing or "justifying" what you're doing, it's much easier to talk about the real subject naturally. It was easier and more fun. Of course the idea is you can ALWAYS do this, and you should.

Hopefully tomorrow it will be easier to be more natural...

Yes, and 7 more things in my closet

Tonight I started a 6-day, 26-hour intensive course on improv comedy. Because I'd like to chronicle what happened and digest it later, the next few blog entries will be a journal without analysis or filtering.

The troupe at Coldtowne Theatre has an interesting history. They started in New Orleans but were displaced by Katrina. Left with no home and little money, they toured the country with their act. After having seen lots of comedy (often at festivals) and many cities, they settled on Austin as their new home. They opened the theater on 49 1/2 and Airport and do shows and classes. "Chicago style" is their thing, meaning the scenes are completely invented. Contrast to "Game style" where situations and structures are put in placed ahead of time as with Who's Line is it Anyway.

The class is made up of 10 guys, most of whom have no experience in comedy or theater. The teachers are pro's (literally) and it shows. There's no "graduation show" scheduled but I said there should be one and our teacher said she'd try to make it happen.

First the warm-ups. The idea is to get you to relax, loosen up inhibitions, and get used to saying the first thing that comes to mind. Don't try to be funny, don't try to make sense. The first was "Throw the dagger." With everyone standing in a circle, a dagger is produced (completely invented of course) and thrown at someone. You catch it in some way, make eye contact with someone else, and throw it. Soon people were catching it with their teeth, getting stabbed, dodging it, using it to cut steak, doing Matrix moves, etc..

The next warm-up was "7 Things." One people is challenged to think of "Seven things that are in your car" or "Seven things that make you mad." As you yell out each thing everyone else yells "Yes!" (which makes it funnier -- one rule of improv is that affirming something ridiculous is inherently funny). The nouns don't matter -- even if it doesn't make any sense at all. You might say "Cats, Barry Manilow, the Earth, food, croquet, pizza, commas," to any proposition. Again you're just supposed to get used to talking out loud, and getting used to not being embarrassed or worried.

The first lesson is the primary rule of improv: The Rule of Agreement. Improv has no props and no set-up, so everything is created on the spot, or "an invention" in the lingo. Both the audience and the other actor must be able to follow the construction. The Rule of Agreement is that once a situation has been established -- even if with a single sentence -- you must not deny its existence.

For example, if someone starts a scene with "Hey Harry, look at that dead hooker," you cannot respond with "That's not a hooker, it's a tulip." This "denial" (the lingo) kills the action. The first person has no response. You can't argue that indeed it is a hooker because now nothing makes sense and no plot is developing. If you agree it's a tulip it still doesn't make sense and there's no development.

We did an exercise called "Yes, and..." to get into the "agreement" mind-set; however it's a common mistake (which Malcolm Gladwell made) to say this is the rule. The exercise is that you do a scene but every line must start with "Yes, and..." You do not have to make the situation more ridiculous, you just get in the mindset of affirmation. In reality you don't necessarily agree with everything -- the typical straight-man/crazy-man routine depends on one person disagreeing with another -- it's that you agree with the current "construction" -- the situation, the scene, the action.

So now that you're not denying the reality that has been invented, now you need some reality! How do you start to build something from nothing?

It turns out that what you're doing in the scene is much less important than who the characters are and their relationship to each other. The interplay between people and the odd mixtures you can get and the way they play off one another is the meat -- the invented props, actions, etc are just a means to convey that.

Given this, the next exercise forced us to think about what our characters were feeling. You do the scene but between each turn you have to pause for 2 seconds to think "What do I feel about this?" Then you have to incorporate that feeling into the response, either directly (e.g. "That makes me mad!") or indirectly (e.g. "Goddammit Billy did you really have to do that?").

For me this exercise did more than just clarify the character's existence. Before, even if we had a good premise to start off the scene it didn't go anywhere. Even with funny characters or situations there was no plot, no development, no action, no interest. When you take the time to think "What would this character feel," you first have to figure out who the character is. And that's when I realized that I don't know! I didn't think about that. And that's why it didn't go anywhere.

It's like Socrates defining his words -- once you define all your terms and everyone else agrees to the definitions, the results fall out automatically. Once you really understand your character, the results of the scene will fall out. Of course you have to be funny and you have to come up with the character immediately, but if you have your own framework you know how to react consistently to the scene.

One way I've heard this said is "Take care of yourself first." (Actually it was "Get yourself off first.") In other words, understand who you are in the scene first and you can always use it to help you through and develop the plot. An "anchor," in yet more lingo.

So don't deny the scene and know who you are. Next lesson is: Listen. Really listen to the other person. Did they just imply something with the last statement? Are they communicating something you should pick up on? If the audience sees that actor A is trying to do something and B isn't playing along, it's not fun, not funny, and stifles the momentum.

We did a few exercises to practice this, but we weren't told what the exercise was beforehand. In one case you had to repeat the scene you just invented, but switch roles. Can you remember everything the other person said? In another you had to deliver the "inner monologue" that the other character would have been going through in the scene.

For me the most interesting point here was not just that you should listen, but what you're listening for. Go back to the point that the characters and relationships are much more important than what they are doing. It's easy to get caught up in the action and get stuck trying to think of the "next thing to do." Inside, remember that the other person has developed a character in her own mind. What is that character? When you're listening, drill into what that character is. Is it "The guy that's angry?" "The guy who's unhappy no matter what?" "The woman who's excited about everything?" If you're picking up on this you can play off it and the actions will come more easily. How would your character react to that character, in general? If you're a tough army guy and she's your neighbor who you secretly admire, how do you interact with her? It doesn't matter if she's walking the dog or going to work or gardening or also in the army or yelling at kids -- the key is your relationship and listening for that in the other person helps you establish this.

So: Agree with reality, know thyself, and listen. (The life-lessons are starting to show...) Next is "locality." Don't tell a story during the scene -- BE the story. Don't talk about what you did two weeks ago -- DO it. Don't talk about what you're going to do tomorrow -- DO it. It's easier to interact and people go to sleep anyway. No exercises on this one but it was a recurring theme.

Next is to stick with your personality/relationship. In one scene I started out as a tough army guy with a gun (a rabbit-shooting gun as it turned out, and by that I mean a gun that fires rabbits). The other guy was a kid who thought the gun was cool. It was working at first but it wasn't going anywhere. The teacher stopped us and said, "OK, start again but this time you ARE the tough army guy who knows everything about the gun and you ARE the kid who is excited about everything no matter what." We did it again and it was hilarious. Owning the parts helped in several ways: (1) Audience could track it, (2) an anchor to reduce variables as you're navigating the scene, (3) something you could count on in the other person, (4) when two personalities do their thing and even clash, especially when it's ridiculous, it's funny.

Yet another rule is: Don't ask Questions. Often a question just pushes a decision onto the other person, rather than helping to build the scene. Furthermore, a question often directs the other person to invent something specific instead of allowing the other person to invent wherever convenient.

For example, player A starts by saying "Why is there a dead hooker over there?" Now B has to come up with a reason for a specific thing that was just invented -- a difficult thing. Instead A could say "Look Harry, there's a dead hooker over there!" Now B has to react to the situation, but B can say and do anything about it. B could say "I'm scared of dead people" or "That's the fifth one today" or "Let's go see" or whatever.

Really this rule isn't that you can't ask questions. It's that you shouldn't put the other person in a position to have to make specific inventions. A question that builds onto the scene can be OK. For example, B could respond, "I'm going to take a closer look. Want to come?" B has developed the scene and A is still open to respond in any number of ways, and again A can rely on his character's feelings to come up with a consistent answer.

The final rule (for today) is: Keep it Simple. When the scene gets complex the audience gets lost and so do the players. Often the first 30 seconds establishes all you need -- when you're scared or blocked you start inventing more things to add to the scene but this doesn't resolve the problem. More invention doesn't help the scene along, it just clutters it and makes it more confusing. This rule was broken the most tonight; when you're stuck it's hard to play within the few structures you have. I think owning your character before you get on stage can go a long way to combat this.

However, all rules can be broken. All are guidelines that help get you going and drive scenes forward. In one scene a general and private ended up switching ranks. The storyline made sense and it was funny -- holding on to "I must remain in this part no matter what" would have broken the momentum.

Well that's all for today. It was a blast! Some of it was easier and other parts were harder than I expected.

When all this is over I hope to be able to tie this up in some meaningful way, and also bring out specific ways in which some techniques are useful outside the theater.

Interview with Dr. Dobbs

Dr. Dobbs editor-in-chief Jon Erickson interviewed me today about about code review.

Read it here.

Bears Again!

In the latest issue of SD Times the bear lives on! This is a scan of the newspaper. That's Brandon in the background.

This continues the saga of the bear.

Editor-in-chief David Rubinstein wrote a great piece on doing code review and had some nice things to say about us.

Full issue in PDF is here; we're on the cover, on page 26, and on page 42.

You're a real company when...

Ever since I started Smart Bear, there's been a running question of "When do you know you're a real company?"

Which of these are true: You're a real company when...

• You have a domain name that isn't weird.
  
• Your business cards don't say "VistaPrint" on the back.
• You take PO's in addition to credit cards, and you've gotten over the fact that, yes, you have to actually ship the product before they give you money.
• You have to switch from Quicken to Quickbooks.
• You hire the first real employee.
  
• You pay someone else to print pay stubs and pay your monthly employment taxes because you're just tired of doing it yourself.
  
• You have a sign on the building.
• A real artist does your website and handouts.
• You have a 256-page color glossy hard-backed book chronicling your ascent in the world (Saw this at Adobe. Gorgeous. I asked everyone I met there about it and no one but the receptionist had ever seen it. It's sitting in the lobby. The receptionist, by the way, knew exactly what their branch of Adobe (Ottawa) did and could articulate why people bought it in about 15 seconds. Her elevator pitch was better than the 10 minute diatribe I got from a senior manager later that day.)

I made one of those bold because that's the one I think has always stuck with me. We got the sign about a year ago, and it really was a proud moment.

Currently Smart Bear has everything but the glossy book (but we do have a book with a glossy cover with over 7000 copies in circulation). The 8000'th user of our various software products just came on-line. That makes me feel like a real company.

Guy in a bear suit

Does your company have a mascot? Ours does. And ours writes Eclipse plug-ins in addition to being a fearsome beast.

Not that I'd normally call Roy fearsome. Formidable, yes, but not fearsome. He juggled flaming clubs on Brandon's wooden back porch ("Don't worry, it's just fire"). I once saw him fixing an obscure bug in our Subversion/Eclipse integration while wearing the complete bear outfit.

So what happens when you put an Eclipse developer in a panda suit and stick him in the aisle at SD West?

1. Everyone notices.
   
2. Most people gravitate to the bear. Gotta see what this is all about. Usually they are smiling.
   
3. A few people will do anything to avoid getting close to the bear or making "eye contact."
4. People assume you've hired some poor high school student to stand around in the suit. So when the bear engages you in a discussion of peer code review you might be surprised enough to actually talk about it.
5. The bear's position in the aisle in front of the booth was unintentionally brilliant because: (a) you have to walk around the bear -- the suit plus personal space creates a significant no-fly zone, plus (b) there was always a crowd around the bear, checking it out, seeing if it could talk, which increases the no-fly zone, therefore (c) if you want to get past the bear you must swing all the way to one side of the aisle (where our booth was) or the other, so (d) you end up getting our pitch and seeing our stuff even if you avoid the bear, especially since (e) the leftover space between bear and booth was so small that it created a logjam so you'd be standing in front of the booth without ability to move so you might as well check out our movie and get a free book.
   
6. At least 10 other vendors at the show commented that "That guy must have lost a bet." Sheesh. Roy really wanted to be the bear, and he was really good at it. He spent a lot of time in the bear head back at the office to get used to where the ears and head and eyes and chin were.
7. If you cup the vestigial ears and bend them forward and say "come again," no one considers that this action doesn't actually allow the human to hear better.
   
8. Not-so-clever Stephen Colbert references abound.
9. Once the bear was propositioned. A woman commented that it would be great to have a bear mow the lawn. Roy said the bear was not for sale, but I thought he should have at least heard her out. Everything can be had for a price, even a mowing bear. Maybe not for Roy.
10. Bears stand out at awards shows. Craig (as in, he has a list) mentioned the bear three times during the ceremony. Eric points out it worked because Roy was not jumping around, calling attention to himself. He was just calmly sitting there, as if it's normal that a bear would be attending the Jolt Award. Which, of course, it is.

P.S. Before you put 2 and 2 together, it turned out to not be a juggling bear. Roy couldn't see well enough out of the... neck... to juggle. He actually got three balls going by throwing them back on his furry belly to reduce error, but it looked weird.