Patterns of failure: how LucasArts fell apart

Over at Kotaku, a Gawker Media web portal that covers computer games (a bigger industry than Hollywood, I might point out), Jason Schreier has an excellent article outlining the fall of LucasArts, once one of the most productive and successful video game companies around, but now no longer in existence. It is worth a careful reading, since it outlines many factors that led to LucasArts’s demise.

One passage in particular struck me. It talking about the game (never released) that eventually became known by the name of Star Wars: 1313:

But the goal posts kept shifting, ex-team members say. Every so often, [George] Lucas would check in with the team, and as he grew to trust the staff behind 1313, he’d offer up changes, asking them to switch characters and rewrite the story based on what he felt would be more fitting for the game. Ex-LucasArts staff describe Lucas as someone who cared deeply about telling stories, but didn’t know much about the game development process—every Lucas-mandated story change meant shifts in every department: the design, the art, the programming. How could that not be frustrating?

“One of the problems of working in a film company—[Lucas] is used to being able to change his mind,” said one source. “He didn’t really have a capacity for understanding how damaging and difficult to deal with these changes were.”

In 2012, just eight weeks before E3, George Lucas dropped a bombshell: instead of starring a generic bounty hunter, 1313 would be helmed by the iconic mercenary Boba Fett. Some staffers tried to push back—they’d spent over two years working under an entirely different vision—but Lucas and his team of executives wouldn’t reconsider. They wanted a game with Boba in it. On top of that, according to two people familiar with the project, 1313’s developers were prohibited from talking about the new hero. When the devs revealed the game and started taking interviews during E3 2012, they had to pretend that 1313 starred the same generic bounty hunter it had for the past two years.

This brought home to me my first-ever programming job. As an undergraduate computer science student at BYU, I landed a job in 1974 with the BYU Translation Sciences Institute, an on-campus research project to develop a computer-aided language translation system. The idea was that the source English text would be analyzed by a human operator via an interactive software system — thus simplifying one of the hardest tasks of computer translation. The result would be a  language-neutral data representation of the source text. That, in turn, could then be synthesized into multiple target languages (I believe the original set of five were German, French, Spanish, Chinese, and Portuguese; I ended up working on the Chinese synthesis software).

The linguistic theory underlying the entire system was Junction Grammar, devised by Dr. Eldon Lytle, a professor of linguistics at BYU and head of TSI. And one of the problems that I encountered on the TSI project parallels the problems described above. We would make significant progress towards a working system — and then every 9-12 months, Dr. Lytle would come up with a major revision or refinement to Junction Grammar that would cause us to have to re-code large portions of the project. This happened all through the four years I worked there, until my graduation from BYU in 1978; in that time, we never reached a ‘completed’ system, and the university ceased funding two years later in 1980.

By contrast, when I was at Pages Software Inc., we actually completed the user manual relatively early, mostly because the product itself was late. Nevertheless, our CEO, Larry Spelhaug, had complete bound and printed copies of the manuals made and gave one to every person at Pages. He held an all-hands meeting and said, “This is what we’re building. If it’s not in the manual, we’re not doing it.” That was a major factor in the product’s eventual successful launch.

Steve Jobs is famous for saying, “Real artists ship.” At some point, you have to freeze features (and, to be honest, you usually have to start dropping features) and get the product out the door. Otherwise, you will never be done.

There are plenty more lessons from Schreier’s article; go read the whole thing. And be sure to read the comments as well.

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.