Time to get a new video card…

Random

Random

While a valid general principle, it turns out that it is incredibly difficult to nail down exactly which of all the features on the table fall into that magical 20%. To be sure, conducting usability studies can help. However, there is no escaping the fact that people are unique individuals. The larger the market you are going after, the more likely you are to end up with overlapping or disjoint 20’s. In other words, my 20% is not your 20%. And this group’s 20% is not the same as it was yesterday. No market is completely homogeneous, no matter how small (even a single individual’s needs change over time).

To put it bluntly, the 80-20 rule is no magic bullet. If successful engineers and business leaders were honest with themselves, they would realize that focusing on the right features is only a piece of the puzzle. Not only does a product have to be useful (solve the right problems), but it also needs to be smart (solve the problems in the right way), and pleasant (appeal to the emotional, social, and ethical needs of the user).

And, of course, you will never get a well-designed widget in the first place if you don’t have the right people and the right process. The point is, you aren’t in control of your success. Principles are. Your job is to put them in place and start the wheels turning.

The needs of your market change over time, and that change accelerates every year as our cultures become more and more globalized. You need to stay on your toes, constantly readjusting your features and process.  Even if things are going well, and you have most of the features in your product that most people want (implemented the way most people like), you simply aren’t done. Jakob Nielsen writes:

Taking a metaphor from the airline industry, it’s now time for you to study “safe flights.” Historically, the airline industry improved safety by studying airline accidents. Modern airplanes now crash so rarely that the industry studies safe flights to achieve further improvements, investigating why flights are safe and whether they had any close calls.

You can always do better.

Random

How about another?

And my favorite…

Go try it out for yourself.  But beware the fun you’ll have!

-ANSI Pants

http://insentient.net/

I would recommend editing shortcuts to add the mouse-in-the-screen-corner shortcut to better emulate the Mac Exposé behavior:

Settings > Shortcuts > Edit Shortcuts > Add Shortcut > Mouse Over Screen

If you have more than one monitor, you can create two mouse shortcuts, one for the top-left of screen 1, and the other for the top-right of screen 2.

Excellent tool. It also works great on a Windows Server 2008 workstation.

Random

Also, have a look at Sergio’s XmlBuilder to see lambdas and reflection put to good use. I like it when the language does work for me so I can keep my code beautiful.

Random

Random

Given Dr. Catmull’s history (he has a PhD in Computer Science), I was expecting a fairly technical talk. To my suprise, he said virtually nothing about technology. What he did talk about was people. It seems that you don’t have to have an MBA to know how to manage people.

Here, in a nutshell, is Dr. Catmull’s business philosphy, broken down into several principles.

Success is Blind

It wasn’t too long ago that SGI was the #1 computer graphics company in the world. Everything was totally groovy. Flush with cash and bravado, SGI decided to go shopping and bought Cray. About the same time they acquired Cray, they also decided to pull out of the PC graphics board market. As it turned out, these were two very unwise decisions.

When life is great, it is easy to overlook problems and make bad decisions. The company feels invincible.

History shows that great companies fail all the time. They lose tons of money and some may even go bankrupt. In most instances, the problems start long before anyone notices anything is wrong. As a company becomes more successful, it also tends to become more blind.

The lesson here is that you can never, ever afford to get comfortable. When things are going really well, you will always have subtle problems trying to sneak in under the radar. Left unchecked, such problems will fester and eventually destroy your business. The solution is to constantly monitor your business, putting aside your personal pride and bias to see what you and others are failing to notice.

No Second-Class Citizens

One of the most subtle and damaging problems that can end up destroying a company has to do with class distinction. After their success with Toy Story, Pixar was excited to move forward with their second animated feature, A Bug’s Life. Early on they realized that they would need to bring on a lot of new production people from L.A. to make the film a success.

Up to that time there had been two primary groups within Pixar: the artists and the technicians. Pixar had worked very hard to make sure that both the technical people and the artists felt like they were on equal footing. Neither was favored over the other. Both were on the same pay scale, and company events routinely brought both groups together. Heck, they were even allowed to intermarry!

Everything was cool. As work began on Bug’s Life, however, Ed began to notice something. The production folks weren’t quite getting along with the artists and techies. Since Toy Story had been such a runaway success, it would have been easy to ignore the problem, or not to have noticed it in the first place. However, Ed and others at Pixar decided to investigate.

As it turned out, the production team had been feeling very much second-class to the other groups at Pixar. Recognizing a danger to their success formula, Pixar started searching for a way to get everyone back on equal footing. It did not take long before they discovered the real problem, of which second-class citizenry was only a symptom.

This is a great example of why it is so important to pay attention to the little problems in an organization. Small issues do not themselves destroy your company. The real danger lies in the rest of the iceberg floating below the surface.

In this story, the iceberg had to do with communication.

Management Hierarchies vs. Communication

When Pixar started looking for a way to better integrate the production group, they discovered a basic flaw in their business model. They had confused management hierarchies with communication channels. For example, if an artist had a question or concern, they could only discuss it with their peers or direct manager. That manager would then pass messages up the chain of command as needed. Unfortunately, the production folks did not have as direct a reporting chain to upper management as did the artists and technicians. They felt like their needs came second to everyone else’s.

The solution was simple: a 100% open-door policy. Anyone could talk to anyone at any time, regardless of position. If a programmer was worried about not having the right tools for his job, he could go straight to Ed Catmull and explain the situation. If someone in production was getting frustrated waiting on something from a programmer, he could go directly to that programmer’s manager. Within a few months of implementing the new policy, the production team no longer felt second-class, and the company was actually more efficient than it had ever been before.

B Work is Bad for the Soul

Pixar discovered another important principle just 9 months before Toy Story 2 was to be released. The idea of Toy Story 2 had been pitched by Disney as a direct-to-video money-maker, and generally followed the “B” movie strategy that Disney had been following. The formula was simple. Release a hit feature film. Quickly churn out a lower quality sequel direct to video, then proceed to haul in boatloads of cash. This they proposed to do with the Toy Story franchise.

Pixar reluctantly agreed to make a lower quality Toy Story 2 film. Accordingly they put together a team and instructed them to only do “B” quality work. Unfortunately, nobody likes doing “B” work. “B work is bad for the soul” explained Dr. Catmull. With 9 months left before the release date, Toy Story 2 was a mess. The story wasn’t working. The team was depressed and didn’t like their jobs. Ed Catmull called John Lasseter, who was in Europe at the time, and told him they had a problem. John quickly returned to Pixar and asked to see the reel. “You’re right,” he said. “This isn’t working.”

The only solution, they decided, was to scrap the whole thing and start over. Toy Story had to be a quality feature film. Pixar simply could not make a “B” movie. After explaining the situation to Disney, Pixar was informed that what they were asking was impossible. Pixar simply could not start over. After all, they only had 9 months left. And there would be no changing the release date. Catmull and Lasseter thanked them kindly for their opinion and then informed them that they were going to do it anyway. The next 9 months were a mad rush, but amazingly enough, they made it.

Take Care of Your People

After the intense 9 month effort to release Toy Story 2, most team members were sore, tired, and burned out. Pixar immediately brought in an army of massage therapists, doctors, and other health professionals. All employees were entitled to free therapy, ergonomics and general health training, not to mention some well-earned time off.

Months later, Pixar discovered that their health insurance provider had been impressed by their efforts and had given them a major discount on their premiums. From this experience, Ed Catmull learned an important lesson: “It doesn’t cost anything to take care of people, and it’s the right thing to do, anyway.”

People know when the company cares, and when it doesn’t. Your employees won’t last long if you aren’t careful to create a great environment, no matter how awesome the project. You have to be on the lookout for signs of trouble. Your employees often won’t tell you until it is too late. Brad Bird agrees:

In my experience, the thing that has the most significant impact on a movie’s budget—but never shows up in a budget—is morale. If you have low morale, for every $1 you spend, you get about 25 cents of value. If you have high morale, for every $1 you spend, you get about $3 of value. Companies should pay much more attention to morale.

Your Name is a Bank Account

If Pixar had released Toy Story 2 as a low-quality film, direct to video, it would have been a terrible embarrassment and made a significant dent in their reputation. Disney spent years chasing this road. While in the short-term they did make a lot of profit, they eventually destroyed their animated film business. I think most people will agree it’s been a long time since they have seen a really great animated film come out of Disney’s animation studio. “B” work has a way of becoming a habit.

Ed quoted Steve Jobs in saying, “Your name is a bank account.” Each time you produce something good, it’s like adding to that account. Each time you produce something poor, you are taking a withdrawal. And if you continue long enough making withdrawals, eventually you will bankrupt your name. This is exactly what happened to Disney. Brad Bird elaborates:

Walt Disney’s mantra was, “I don’t make movies to make money—I make money to make movies.” It seems counterintuitive, but for imagination-based companies to succeed in the long run, making money can’t be the focus.

Making their name synonymous with quality is one of Pixar’s fundamental goals. They routinely spend enormous amounts of time and money to ensure not only the quality of their films, but of the entire franchise surrounding each animated feature. They work closely with the toy and book companies that manufacture Pixar merchandise to ensure that when it says Pixar on the label, customers can expect an exceptional product.

The Project Postmortem

People don’t like doing postmortems, but they like the information they get out of them. After every project, Pixar does a formal postmortem to assess both what went right, and what went wrong. As you look at each problem, it is important to read between the lines. Circumstances, assumptions, timing, and relationships, and other factors must be considered during the analysis.

Once you understand the driving forces behind your failures and successes, you must get to work improving the bad and reinforcing the good in your organization. Learn from the past and make the future even better.

Conclusion: A Film is Not an Idea

A lot of people think a business or a product is an idea. In fact, Pixar gets sued for each and every film they make. Someone inevitably comes along, claiming that Pixar stole their idea. For example, an individual once had a story idea for monsters hiding under the bed. They claimed that Pixar had stolen their idea to create Monsters Inc.

These people simply don’t get it. A great film or product is not just one idea. It is a collection of thousands and thousands of ideas from many different people. Putting these ideas together is like working on a jigsaw puzzle. If you want to make the picture look right, you have to find all the right pieces and put them in the right places. Any ideas that don’t fit have to be discarded.

Don’t try too hard to come up with one great idea. The first thing to focus on is getting a team of smart, motivated, creative people working together. Then you give them some freedom and a little guidance. At the end of the day you will get a great collection of ideas that fit together well, ultimately resulting in a successful project. This principle is so important to Pixar, that they have a division whose sole purpose is to organize great teams.

When you are successful, remember that it wasn’t just your great idea that made the difference. It was the combination of many great ideas from many talented people. Oh, and please don’t forget to say thank you.

Derived from a CS colloquium given by Dr. Ed Catmull at Brigham Young University on March 27, 2008.

See also: How Pixar Fosters Innovation

However, when you are working on your VPS or some other server box without a window manager, VIM can save your bacon. Using VIM involves memorizing many keyboard shortcuts; some intuitive, and some not. Recently I came across a great VIM cheat sheet by Nana Långstedt that I wanted to share. I like this one in particular because it includes a few commands, like “open line above” that are sadly missing from many other cheat sheets.

So whether you are on the road to becoming a VIM ninja, or just need to do some remote text surgery, Nana’s VIM cheat sheet is where it’s at.

Dr. Destructor: Wait till I get going! Where was I?

Capt. Constructor: Australia. Oh wait. I mean, you were just telling me about spheroids, buckets, and a scale.

Dr. Destructor: Right! I, like many non-virtual Destructors out there, suffer from occasional memory leaks. Don’t tell me you Constructors are immune. Australia? Ha!

Capt. Constructor: Memory and Australia are both quite entertaining topics. But if you’ll excuse me, the world is on the verge of collapse and I hear some spheroids calling my name.

Spheroids: O Captain! my Captain!

[Our hero dashes to the Table of Doom whereon are arranged the spheroid-filled buckets and the badly damaged scale. He buries himself in thought for a full 100 milliseconds, which is an eternity to a modern microprocessor.]

Capt. Constructor: Aha! The solution is simple. One can conceptually number the buckets 0 through 9. Once that is accomplished, the following algorithm should suffice:

void transferSpheroids(int howMany, Bucket& from, Bucket& to)
{
	// The contents of this function are left as an exercise
	// for the reader.
}

const int numBuckets = 10;
const float normalWeight = 1.0f;
const float abnormalWeight = 1.01f;
const float singleWeightDiff = abnormalWeight - normalWeight;

// See http://en.wikipedia.org/wiki/Arithmetic_progression on why
// this works.
const float expectedWeight = numBuckets * (numBuckets - 1) * normalWeight / 2.0f;

int findHeavyBucket(int buckets[])
{
	for (int whichBucket = 0; whichBucket < numBuckets; whichBucket++)
	{
		transferSpheroids(whichBucket, buckets[whichBucket], this.EmptyBucket);
	}

	float actualWeight = scale.Weigh(this.EmptyBucket);
	float totalWeightDiff = actualWeight - expectedWeight;

	return (int)(totalWeightDiff / singleWeightDiff);
}

int main()
{
	// Set up the buckets, etc.
	// …

	int bucketContainingHeavies = findHeavyBucket(buckets);
}

Capt. Constructor: Of course there may be a syntax error or two in there. You’ll forgive me for not bringing my pocket compiler.

Dr. Destructor: Arg! Foiled again! How were you able to solve it so quickly?

Capt. Constructor: You made the mistake of labeling each of the buckets 0 through 9. That was just the clue I needed. It otherwise might have taken me 300 milliseconds or more.

Dr. Destructor: Curses!

Capt. Constructor: Remember, Destructor, nefariosity does not pay.

Dr. Destructor: I believe you mean nefariousness.

Capt. Constructor: Whatever.