Writing

Dick Brass

An interesting op-ed by Dick Brass, a former Vice President at Microsoft on how their internal structure can get in the way of innovation, and citing specific examples. The first relates to ClearType and the difficulties of getting it integrated into other products:

Although we built it to help sell e-books, it gave Microsoft a huge potential advantage for every device with a screen. But it also annoyed other Microsoft groups that felt threatened by our success.

Engineers in the Windows group falsely claimed it made the display go haywire when certain colors were used. The head of Office products said it was fuzzy and gave him headaches. The vice president for pocket devices was blunter: he’d support ClearType and use it, but only if I transferred the program and the programmers to his control. As a result, even though it received much public praise, internal promotion and patents, a decade passed before a fully operational version of ClearType finally made it into Windows.

Or another case in attempts to build the Tablet PC, in stark contrast to Apple’s (obvious and necessary) redesign of iWork for their upcoming iPad:

Another example: When we were building the tablet PC in 2001, the vice president in charge of Office at the time decided he didn’t like the concept. The tablet required a stylus, and he much preferred keyboards to pens and thought our efforts doomed. To guarantee they were, he refused to modify the popular Office applications to work properly with the tablet. So if you wanted to enter a number into a spreadsheet or correct a word in an e-mail message, you had to write it in a special pop-up box, which then transferred the information to Office. Annoying, clumsy and slow.

Having spent time in engineering meetings where similar arguments were made, it’s interesting to see how that perspective translates into actual outcomes. ClearType has seemingly crawled its way to a modest success (though arguably was invented much earlier with Apple ][ displays), while Microsoft’s Tablet efforts remain a failure. But neither represent he common sense approach that has had such an influence on Apple’s success.

Update: A shockingly bad official response has been posted to Microsoft’s corporate blog. While I took the original article to be one person’s perspective, the lame retort (inline smiley face and all) does more to reinforce Brass’ argument.

Thursday, February 4, 2010 | cs, failure, software  

Sustainable Creativity at Pixar

pixar_photo5_blursharpen.jpgGiven some number of talented people, success is not particularly surprising. But sustaining that success in a creative organization, the way that Pixar has over the last fifteen years is truly exceptional. Ed Catmull, cofounder of Pixar (and computer graphics pioneer) writes about their success for the Harvard Business Review:

Unlike most other studios, we have never bought scripts or movie ideas from the outside. All of our stories, worlds, and characters were created internally by our community of artists. And in making these films, we have continued to push the technological boundaries of computer animation, securing dozens of patents in the process.

On Creativity:

People tend to think of creativity as a mysterious solo act, and they typically reduce products to a single idea: This is a movie about toys, or dinosaurs, or love, they’ll say. However, in filmmaking and many other kinds of complex product development, creativity involves a large number of people from different disciplines working effectively together to solve a great many problems. The initial idea for the movie—what people in the movie business call “the high concept”—is merely one step in a long, arduous process that takes four to five years.

A movie contains literally tens of thousands of ideas.

On Taking Risks:

…we as executives have to resist our natural tendency to avoid or minimize risks, which, of course, is much easier said than done. In the movie business and plenty of others, this instinct leads executives to choose to copy successes rather than try to create something brand-new. That’s why you see so many movies that are so much alike. It also explains why a lot of films aren’t very good. If you want to be original, you have to accept the uncertainty, even when it’s uncomfortable, and have the capability to recover when your organization takes a big risk and fails. What’s the key to being able to recover? Talented people!

Reminding us that we learn more from failure, the more interesting part of the article talks about how Pixar responded to early failures in Toy Story 2:

Toy Story 2 was great and became a critical and commercial success—and it was the defining moment for Pixar. It taught us an important lesson about the primacy of people over ideas: If you give a good idea to a mediocre team, they will screw it up; if you give a mediocre idea to a great team, they will either fix it or throw it away and come up with something that works.

Toy Story 2 also taught us another important lesson: There has to be one quality bar for every film we produce. Everyone working at the studio at the time made tremendous personal sacrifices to fix Toy Story 2. We shut down all the other productions. We asked our crew to work inhumane hours, and lots of people suffered repetitive stress injuries. But by rejecting mediocrity at great pain and personal sacrifice, we made a loud statement as a community that it was unacceptable to produce some good films and some mediocre films. As a result of Toy Story 2, it became deeply ingrained in our culture that everything we touch needs to be excellent.

On mixing art and technology:

[Walt Disney] believed that when continual change, or reinvention, is the norm in an organization and technology and art are together, magical things happen. A lot of people look back at Disney’s early days and say, “Look at the artists!” They don’t pay attention to his technological innovations. But he did the first sound in animation, the first color, the first compositing of animation with live action, and the first applications of xerography in animation production. He was always excited by science and technology.

At Pixar, we believe in this swirling interplay between art and technology and constantly try to use better technology at every stage of production. John coined a saying that captures this dynamic: “Technology inspires art, and art challenges the technology.”

I saw Catmull speak to the Computer Science department a month or two before I graduated from Carnegie Mellon. Toy Story had been released two years earlier, and 20 or 30 of us were all jammed into a room listening to this computer graphics legend speaking about…storytelling. The importance of narrative. How the movies Pixar was creating had less to do with the groundbreaking computer graphics (the reason that most were in the room) than it did with a good story. This is less shocking nowadays, especially if you’ve ever seen a lecture by someone from Pixar, but the scene left an incredible impression on me. It was a wonderful message to the programmers in attendance about the importance of placing purpose before the technology, but without belitting the importance of either.

(While digging for an image to illustrate this post, I also found this review of The Pixar Touch: The Making of a Company, a book that seems to cover similar territory as the HBR article, but from the perspective of an outside author. The image is stolen from Ricky Grove’s review.)

Tuesday, September 9, 2008 | creativity, failure, movies  

The Importance of Failure

This segment from CBS Sunday Morning isn’t particularly groundbreaking or profound (and perhaps a bit hokey), but is a helpful reminder on the importance of failure. (Nevermind the failure to post anything new for two weeks.)

Duke University professor Henry Petroski has made a career studying design failures, which he says are far more interesting than successes.

“Successes teach us very little,” Petroski said.

Petroski’s talking about bridges, but it holds true for any creative endeavor.

Also cited are J.K. Rowling bottoming out before her later success, van Gogh who sold just one painting before his death, Michael Jordan not making his high school basketball team, and others. (You’ve heard of these, but like I said, it’s about the reminder.)

It also notes that the important part is also how you handle failure, citing Chipper Jones, who leads baseball with a .369 batting average, which is impressive but also means that he’s only getting a hit one in three times he has a chance:

“Well, most of the time it’s not [going your way] and that’s why you have to be able to accept failure,” Jones said. “[…] a lot of work […] here in the big league is how you accept failure.”

Which is another important reminder: the standout difference in “making it” has to do with bouncing back from failure.

And if nothing else, watch it for footage of the collapse of the Tacoma Narrows Bridge in 1940. Such a beautiful (if terrifying) picture of cement and metal oscillating in the wind. Also linked from the Wikipedia article are a collection of still photographs (including the collapse) and links to newsreel footage from the Internet Archive.

Friday, August 15, 2008 | failure  
Book

Visualizing Data Book CoverVisualizing Data is my 2007 book about computational information design. It covers the path from raw data to how we understand it, detailing how to begin with a set of numbers and produce images or software that lets you view and interact with information. When first published, it was the only book(s) for people who wanted to learn how to actually build a data visualization in code.

The text was published by O’Reilly in December 2007 and can be found at Amazon and elsewhere. Amazon also has an edition for the Kindle, for people who aren’t into the dead tree thing. (Proceeds from Amazon links found on this page are used to pay my web hosting bill.)

Examples for the book can be found here.

The book covers ideas found in my Ph.D. dissertation, which is the basis for Chapter 1. The next chapter is an extremely brief introduction to Processing, which is used for the examples. Next is (chapter 3) is a simple mapping project to place data points on a map of the United States. Of course, the idea is not that lots of people want to visualize data for each of 50 states. Instead, it’s a jumping off point for learning how to lay out data spatially.

The chapters that follow cover six more projects, such as salary vs. performance (Chapter 5), zipdecode (Chapter 6), followed by more advanced topics dealing with trees, treemaps, hierarchies, and recursion (Chapter 7), plus graphs and networks (Chapter 8).

This site is used for follow-up code and writing about related topics.