Robert V. Binder

Is Making Movies Like Making Software?

June 20, 2011  |  Blog, Business, Process, Software Products

Avatar-teamAfter proving that good project management and software engineering could result in on-time, in-budget, high quality results for contract software development, I was designated as the project manager of a large fixed-price development project. Despite my objections, a second project manager was also assigned to this project. The relationship was explained as “like the director (me) and producer (the other fellow) of a movie.” This 18 month project came in on time, under budget, and had only 1 bug in its first production release. On reflection, this producer/director arrangement did contribute to its success.

Since then, I’ve wondered about what the software development community could learn from the making of movies.

To start with, how does software development resemble making movies? A unique creative and/or commercial vision is defined and funded. A team of diverse specialists is assembled, often with prima donnas that need to be coddled to extract peak performance. “Chemistry” among the principals is central to success. The management of practical (producer/project manager) and creative (director/architect) aspects are often separate and conflictual. Besides the stars, hundreds of technicians and specialists must collaborate to achieve a common vision. The extent to which this central vision survives or is enhanced as the collaborative process unfolds is critical to coherence. Then, once in the can, identical, localized copies of the work product are presented to a mass market for its judgement.

There are significant differences. Movie sequels almost never improve on the 1.0 version. For the viewer, movies are necessarily a time-sequential single-path narrative; software has a huge extent of unique possibilities. A good editor can cut out weird and bad paths; a good tester is lucky to find them. As viewers, we only rely on a movie for a few hours of entertainment; as users, we may be risking our health and wealth.

These added dimensions provide the engineering imperative for software. Many people have argued that software development could beneficially learn from manufacturing, or at least from certain techniques (resuable off-the-shelf components and six sigma QA for example.)  However, the dynamics that focus hundreds of technical specialists to produce a movie probably has more to tell us about making software than a study of repetitive manufacturing processes.

The relative importance of a unique development effort versus creating copies of the resulting artifact is the key difference. In all software projects I know of, the development effort is unique and dominates the quality and effectiveness of the artifact. The copying (manufacturing) work is straightforward and simple. There are a very wide range of manufacturing processes (automobiles versus oil refining, etc.), but generally the repetitive work is where value is created and quality is determined. Engineering development work (design of the vehicle and/or the plant) is necessary, but does not dominate results to the extent it does in software.


  1. Perhaps not so much like making a movie as making one of the current episodes of Orange County Choppers — lots of angst, poor planning/execution, family bitterness, and maybe a worthwhile product at the end…

    • Robert V. Binder

      I’ve been in a few situtations that were like the OC Chopper “reality.” Scale seems to be the difference — OCC projects are such that a few skilled mechanics can get the job done in several weeks. Apart from the personalities, OCC is also a “job shop”, which is also suggested as similar to software development.

  2. In both software and movies, there is a range of different amounts of control the director may choose to exercise. Some directors like to call all the shots. Others are more willing to let the actors and cameramen experiment to find what works for a given scene. I haven’t actually worked in movies, but I get the sense that movie directors are often more explicit with their team about where on this spectrum they intend to operate. I’ve seen software teams where everyone operates in a style they are most comfortable with, and then the team gets frustrated when those styles don’t mesh well.

    Perhaps software managers can learn to be more intentional about choosing a “style” of management and communicating to the team what that chosen style is.

    • Robert V. Binder

      I’m reading Sidney Lumet’s “Making Movies” and I recently watched the BlueRay release of “The Wild Bunch”, which contains an in-depth presentation of Sam Peckinpah’s process. Lumet was a meticulous planner who used this preparation and subtle psychology to get the most from his actors. At least with the Wild Bunch, Peckinpah worked from a general concept, and when the talent could pull it off, would let things evolve. So, yes there is a lot variation among directors, and from one project to the next.

Leave a Reply

Comment moderation is enabled, no need to resubmit any comments posted.