In the meantime, I just wanted to take a moment to summarize my current thoughts on the Ruby+POSIX vs. .NET+Microsoft stacks, having spent the last several years jumping back and forth between the two ecosystems.

Core dump:

• Visual Studio is extremely powerful. Their debugger is heads and shoulders above gdb, rdb, and pretty much any other *db on the planet.
• Static typing and compiled code is a nice security blanket when it comes to typos and refactoring. Yes, I’m addicted.
• Every Microsoft event I’ve been to in the last several years has felt stiff and enterprisey. The ecosystem is definitely headed more towards the world of IBM and Oracle, and farther away from the world of Apple and Google.
• The higher the suits/t-shirts ratio, the less fun and interesting things get. Microsoft isn’t fun anymore.
• On the other hand, the open-source/POSIX community is becoming more fun and interesting all the time. The community is vibrant, inventive, and supportive. They are more interested in the joy of the craft than in making a buck (although they do that too).
• The RoR community has grown up a lot in the past few years. We now have lots of lessons-learned and best practices to reference.
• CodePlex and NuGet are steps in the right direction, but aren’t really changing the wider Microsoft culture.
• MongoDB? Awesome. Linux? Awesome. Nginx? Awesome. Ruby 1.9? Awesome. Vim? Debatable.
• With the advent of Ruby 1.9, performance is now good enough. Character encoding woes are a thing of the past. The only thing I miss is my compiled-code security blanket. On the other hand, RSpec and Cucumber give me warm fuzzies.
• It’s a real shame that Python seems to be winning the mindshare war over Ruby. In my own experience and not-so-humble-opinion, Ruby is far more elegant, and package management is better. Python feels like a strange marriage of PHP and Ruby. The only thing that tempts me about Python is it’s speed (esp. PyPy), but recent releases of Ruby are fast enough for my needs.

Bottom line: The better performance and IDE are no longer as compelling an argument to stick with the .NET stack.

But wait! There’s hope! Nancy, Mono, Owin, etc. provide evidence that the .NET community is taking matters into their own hands. Stay tuned…

I have long held the belief that the best way to get more customers is to actually care about them as human beings. In fact, profit is just an unfortunate side-effect of helping people.

Care about people? Really?!

I know, I know… it’s a shocking philosophy. But think about it. Most people today walk around with frightening mental battle wounds as a direct consequence of popular business tactics. They have come to suspect that most salespeople and marketers are out to get them, just trying to make a buck at their expense; trying to trick them into buying stuff they don’t really need, and certainly can’t afford.

And there’s a very good reason for that. It’s true.

Besides demonstrating the uncompromising behavior of our politicians in a time of crisis, the current recession has made it obvious that the old ways of doing business are unsustainable. It just leads to people buying stuff they can’t afford, investing in things they don’t understand, and then watching as their hard-earned money get’s shoveled into the back pockets of smug executives–who, by the way, don’t deserve one penny of it. (Well, maybe one penny.)

Do you want a company that can outlast the next fill-in-the-blank-bubble? Then it’s time to stop taking advantage of people and tricking them into buying your product (otherwise known as “marketing”). There are far more sustainable ways of doing business (or, at least, ways that are less soul-damaging). If you have to trick your customers into buying your product, it’s a sure sign that your business model is broken.

When I was 15, I had life pretty well figured out. I was ready to change the world, walking around with a head full of lofty aspirations, among other things. But more importantly, I needed money for video games. So after school got out for the summer, I joined the fast-food industry.

Surprisingly, I didn’t make much money, but it was almost worth it for the occasional free shake (hey, I was 15). Those were busy days, and despite the superior culinary prowess usually attributed to the fast food industry, we occasionally made mistakes. Sometimes it was no big deal, like forgetting to put napkins in the bag. Other times, it was more serious, like forgetting the fry sauce (hey, don’t mess with a man’s fry sauce). And once in a while tragedy would strike, like the time we gave out a rare hamburger (apparently there are people who eat these, but our customer, tragically, wasn’t one of them). Gross.

When a mistake was particularly bad, my manager would employ a certain magical technique on irate customers. She could turn mad-as-h-ee-double-hockey-sticks-I’ll-never-come-back into cool-thanks-I-love-you-guys in about 5 seconds flat.

The secret weapon? Bread.

But not just any bread. The mom-and-pop’s drive-in where I worked was very famous for their homemade bread. And for good reason. Every morning at about 4:00 a.m., the manager’s husband would come in, turn on the radio, and get to work baking the best bread you would ever have in your life. I mean, this stuff made grandmother’s bread taste like hot-buttered dirt.

So, when facing an irate customer, my manager would pull out a loaf or two of fresh-baked bread and present them with a smile and an apology. Then the magic happened. Angry looks of death disolved instantly into a greatful smile. “Now, here is someone who actually cares about my problem,” the customer would think to themselves as they walked away.

This story illustrates the simple power of gifts. Like any other true principle, generosity is universally applicable and deeply powerful:

• When people receive a genuine gift, they naturally want to reciprocate. In business and in personal relationships, reciprocation is what we call a Very Good Thing.
• When you sincerely give something to someone, you are forced to focus outside of yourself. You gain a better sense of other people’s needs, which in turn lets you be better at providing solutions in the future.
• An unexpected gift sends the message that you really care, and people naturally trust those who care about their personal projects and problems.
• You feel awesome because you did the right thing. Karma++;

The basic idea is you need to give away something valuable that people normally expect to pay for. The act has to be thoughtful, genuine, unbiased, with no argyle socks in sight (don’t even mention them). You give on an ongoing basis, yet at unexpected times. Don’t make yourself too busy to take a moment once in a while to think about the needs of people around you.

Here are some examples:

• Comcast calls you up randomly and says they would like to give you a free month of service for being a loyal customer, then wishes you a good day and hangs up. You check your next bill, and sure enough, it says you owe a grand total of $0.00 for last month’s service.
• One day after a good lunch at a local restaurant, your server brings you your check and hands you a coupon for a free entrée the next time you come in. In fact, all of your coworkers at the table receive the same coupon. The server explains that each day a table is chosen at random to receive a customer appreciation coupon.
• You just went through the not-exactly-stress-free process of moving to a different state and buying a new home. As you are moving in you realize there are a few small repairs you need to make around the house, and the deck needs to be re-stained. A day or two later you get a gift card for Home Depot from your Realtor, along with a thank-you note and their contact information.
• Microsoft runs a promotion where you can type in your email address and they will pick a random 50% of the first 10,000 submissions to get a free copy of Windows 7.
• The waiter at a local Italian restaurant notices you come in on a regular basis, and rewards your patronage with a free appetizer or dessert each time you visit.
• As an engineer, you love gadgets. At seemingly random times, but often during particular difficult projects, the boss buys everyone in the office something cool from ThinkGeek.com.
• You are a web developer and sick of all the hoops you have to jump through to make a web application. While browsing online one day you come across Ruby on Rails and immediately jump out of your chair shouting, because it is bursting at the seems with pure awesome (Rails, not your chair). “Who did this!?” you wonder. It doesn’t take you long to discover 37signals and their excellent web applications. Then, a few months later, you are looking for a good project management tool…

If anything like the above were to happen in real life, how would it make you feel? Would you tell anyone about it? What would you do next?

I think you know the answer.

A few days ago my family called to tell me there had been a fire at my parent’s house. Luckily, everyone got out OK. But they lost almost everything they owned.

It’s made me think a lot about what’s really important. When I leave this life, I won’t even get to take the clothes on my back. All I’ll have is my legacy, my relationships, and my soul.

Hackers tend to get obsessive about projects they are working on or companies they are trying to start. They would do well to ease off some and spend more time serving their community and being with the people they love.

Because, at the end of the day, that’s all you’ve got.

Unfortunately, we all have this same basic bit of stupidity wired into our brains. It makes you want to be in front, even when deep down inside you just know it isn’t going to get you there any faster. You see, if I can be in front of you, I get to pretend I’m in control. I get to pretend that I didn’t wake up late this morning, and that it’s all your fault I’m late for work.

This is what I call the Illusion of Control, a principle that pops up in all kinds of places. For example, there are still a few old-school h4k0rz around who long for the ancient days of magic, wizards, and assembly programming. I actually met one the other day. During an interview for an open position at my company, one candidate commented that he missed the feeling of control that programming in opcodes gave him, and would jump at the chance to go back to pushing bits around if only he could find someone to pay him to do it.

Now, that’s hard-core. Assembly language isn’t exactly the most productive language. And in spite of popular belief, the resulting code often runs slower than what an optimizing compiler would typically generate. Not to mention the maintainenance tax you incur. Then, while you’re busy with that, the world moves on and your competitors quickly release 10 new versions of their own products using more wrist-friendly languages such as Ruby, Python and C#.

Let’s switch gears for a moment and look at another example of the Illusion of Control. It has to do with text editors, and the Illusion of Control is especially insidious in this case (look closely and you can see it smirking).  For some reason, people tend to get emotionally attached to their editor of choice. I’m not sure why that is, but it does reinforce the Illusion of Control.

On one side of the table, you have things like VI and Emacs. These are glorious little programs that let you edit code faster than anyone else on the planet. All you have to do is press ESC, Ctrl-Alt-Shift-X-K, Meta-Karate-Chop and throw your mouse out the window. Bam! Done! Users of such products are the specific target market for products like this.

On the other side of the table, you have text “editors” like Notepad. Absolutely appalling. You might as well go all the way and start typing with your elbows. Or some of these. Actually, I know people who use Notepad to edit new languages that their favorite IDE doesn’t support yet. It makes me cry myself to sleep at night, just thinking about it.

Finally, in the middle of the table we have apps such as TextMate, Coda, Visual Studio, Eclipse, etc. These guys generally strive for a balance between mousing and keyboarding, allowing people to pick and choose more or less of each paradigm to suit their fancy. Not surprisingly, most of the world uses these editors.

Why, given the choices, would any sane person choose VI or Emacs? Other than the ability to run it in a text-only terminal, it’s mainly because these programs make people feel more in control (especially once they start to learn some of the more subtle commands). It’s like being part of some ancient, powerful priesthood. And when they feel more in control, they think they are going faster (or at least winning friends and influencing people). Once in a while they may actually be right. However, Bruce “Tog” Tognazzini and others have shown more than once that in general, heavy use of keyboard shortcuts only makes you think you are going faster, when the reality is quite different. That sounds suspiciously like passing cars to me. Or assembly programming. Or the latest GMail tip floating above my inbox, desperately trying to get me to use some keyboard shortcut. Curious.

So is the Illusion of Control a bad thing? I suppose it depends on your goal. If you are just trying to get things done (i.e., go faster), I think it’s better to remove all illusion so you don’t get distracted from the real bottlenecks (e.g., sleeping through your alarm in the morning is the real problem, not that the guy in front of you who is going 2 mph too slow). However, if you are looking to show off some m4d h4x0r sk7lz, or simply feel like keyboard shortcuts are better for the environment or make you a better person, go right ahead. I won’t stop you.

After all, everyone needs skills.

New! See our recommended reading list for principle-based engineering.

While I don’t remember all the questions he asked during that phone interview, I do remember him pausing at one point, right after I explained that at one of my jobs I had rewritten a particular application from scratch. He asked me: “so, approximately how many total lines of code were in that app?”

I honestly did not know.

So I tried to explain that the actual number didn’t matter. In the end, however, he continued to press me until I finally just gave an educated guess. That seemed to satisfy him, and we moved on with the interview. It seems that he was trying to figure out whether I had ever worked on any large projects before. Unfortunately, I would argue, he was using the wrong metric.

Since that interview, I’ve experienced and read much to make me distrust software engineering metrics. The truth is, most metrics are used incorrectly. And there are some that shouldn’t be used at all.

Let’s take lines of code as an example. The problem with trying to equate large amounts of code to productivity, quality, or talent, is that a great hacker actually writes a lot less code than a mediocre programmer, not more. Why? Great hackers deeply understand and religiously follow proven principles, such as DRY. In addition, good programmers tend to favor terse programming languages.

So, you might think you can just start looking for people who have apps made up of only a few lines of code, right? Wrong. Depending on the tools and frameworks you use, you can end up with thousands of lines of boilerplate code just to set up an application that doesn’t do anything yet. (This type of code is usually written by code generators). Then you start adding things like a static OR/M and suddenly you’re a coding genius! Look at all the code you’ve written!

OK, wait a minute. I thought we were trying to write less code? Well you are, but you aren’t. Are you starting to see the issue?

Here’s the rub: If you want to measure how significant a project is, or whether someone has any talent, stop using incidental metrics and get to the heart of the issue. It’s simple. Just ask yourself, “how useful is this piece of code?” If software isn’t useful (heck, even games are useful in their own way), then what’s the point? Who cares if a piece of software was written in only one week and contains 2.4 million lines of code? If the result is a buggy, hard-to-maintain, unusable pile of steaming rubbish, the programmer has no talent. Period.

Counting lines of code isn’t the only metric getting more attention than it deserves. <insert Sarah Palin joke here>

As another example, take the way experience is measured. Pointy-haired bosses seem to love counting years of experience. And yet time and time again, I have seen young, less-experienced hackers code circles around senior industry veterans. They write better apps in less time with fewer people and sell them on better-looking websites, all while having more fun.

The problem with counting years of experience is that you miss the qualitative analysis. Yes, Joe Engineer has 25 years of experience, but doing what? Did you just do it for the day job, or did you also work on side projects at home? How much effort have you put into self-evaluation and educating yourself on best practices? Are your communication skills any good or do you have silo-syndrome?

Software engineering is still a relatively young field, compared to other disciplines. And, as with any other new field, things change fast. Insanely fast. To excel, you simply can’t do things the same way you did them last year. Needless to say, if you aren’t plugged in to the latest practices, frameworks, and platforms, you will soon become obsolete. While the basic principles of good software development do not change, people, tools, and opportunities do.

Consider what would happen if your doctor decided to stop reading medicine journals and give up educating himself on new procedures. He’s a good doctor. Knows how the body works, right? And besides, it’s a pain to keep up on all the new stuff. Change is hard. He simply doesn’t have the time to keep up on all the latest developments in his field, the way the insurance companies have him over a barrel these days.

Now, flash forward two years: The Cancer Research Institute announces they have a cure for cancer! Hooray! The doctor may hear about it from a friend or on All things Considered during his drive home. But he doesn’t really know how it works. In fact, it relies on several other cutting-edge skills he hasn’t taken the time to learn. If you got cancer and are looking for a physician, who would be you first pick? Why?

Past experience is simply not a good measure of someone’s ability to meet present-day challenges. Someone can have 25 years of experience, and still be a terrible programmer. Only those who are constantly learning, growing, and have a solid aptitude for writing code are going to be any good at what they do. People like Scott Hanselman do it. So can you.

At the end of the day, it’s the portfolio that matters. Stop measuring things indirectly. Instead, get to a place where a great product is being developed. Then, if you really must measure lines of code, at least reward people for creating the same great product more efficiently, with less time, code, and experience. Not more.

We’ve created a level playing field where experience doesn’t matter. The only thing that matters is your work…. Good designers do very well in this model because, very simply, they are good designers.

- Ross Kimbarovsky

New! See our recommended reading list for principle-based engineering.

The System z10 Enterprise Class—equivalent to approximately 1500 Intel x86 servers

IT people like to hang out at Starbucks discussing things that really matter, such as what Russia is doing in Georgia, or what the utilization numbers look like for the company’s servers. The sad reality is that most servers are provisioned with way more hardware than they need for the job. They may see occasional usage spikes, but the CPU is usually just havin’ a bud. This is mostly due to the secret desire of every nerd to own the baddest, most awe-inspiring box on the planet. (This is second only to their fascination with robots.)

Now, there are really only a few ways you can justify all that muscle (without actually disclosing the truth):

1. Slap a database on it. It’s a well-known fact that the average database needs at least 8 cores and 32 GB of RAM.
2. Use it to run Ruby on Rails. Or Twitter.
3. Sell the extra capacity, kind of like what Amazon does.
4. Find more users. Unfortunately, this would require more work and less time playing WoW.

But should you even care that your systems are underutilized? Jeffrey Birnbaum, CTO at Merrill Lynch, has spoken out about better datacenter utilization. However, he warns against using more than about 80% of your resources, saying that this would leave your system unprepared for “unexpected circumstances”. This is good advice.

So, if striving for 100% efficiency is a bad thing for servers, what makes business managers think that it is somehow a good thing for people? Any real business has customers. And customers are the very definition of unexpected circumstances. Not to mention what your competitors might pull out of the hat. Organizations need to chill out a bit, just like their servers. There is no other way to remain agile and flexible.

When was the last time you heard some business leader say they wanted their organizations to be slower and less innovative? That they would rather not respond effectively to changing markets, thank you very much. Oh yes, and could my competition please come kick the crap out of me, please?

Forget about it. Stop stressing about keeping everyone working 100% of the time, and you may just find that people actually have more time to think about better ways of doing things. They won’t burn out. They might actually get some sleep once in a while instead of guzzling Red Bull all day.

And, ironically, they may just get more done.

P.S. – For further reading on the subject, I highly recommend The Goal and Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

New! See our recommended reading list for principle-based engineering.

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

New! See our recommended reading list for principle-based engineering.

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

New! See our recommended reading list for principle-based engineering.

So here’s the principle: one of the best ways to exercise your brain and explore ideas is by writing. This works even if nobody ends up reading your stuff, and works even better when there is any possibility (however likely) that your writing will be read by others. For some reason, we humans do better when we feel accountable.

When I ran track and cross-country with some friends in high school, we learned early on the value of having a running partner. When you have someone to “pace” yourself against, suddenly you have more motivation to run harder and longer (basically until you puke). Writing essays or creating software works the same way. You need a great team of people to motivate you and keep ideas fresh. You also need readers or users for the same reason.

Writing down your thoughts and creating real solutions to peoples problems not only makes the world a better place, but it also makes you a better person.

Share what you know. Be good.

Random Boy

New! See our recommended reading list for principle-based engineering.