Goals! Prototypes! Action!

A thread in comments on a post from Michal Migurski got me thinking about the analogy of film making to software design and development. The more I explored the idea, the more multi-faceted the analogy became.

Movies and software are both very creative and very custom-craft intensive. They are both extremely collaborative — moreso than almost any other endeavor. Both encompass a wide range of styles, audiences, scale, and budget. For each there is a relatively subjective determination of completeness, that point at which the product is ready for release. And history is littered with spectacular successes, and failures, both within and outside the formal "system."

We can learn a lot by looking at parallels between film making and software, if only to recognize the issues we face around budgets, timelines, clarity of direction, conceptual and tactical authority are not unique. We can recognize that there are numerous models to adopt or avoid as the situation demands. It allows us to examine the interplay of money, talent, ego, authority, collaborative energy, role specialization, and market forces at a comfortable distance while learning lessons applicable to our own work.

To begin, let's establish a basic model that compares the film making process to the software making process. In a loosely time-based perspective, consider these parallels:


Naturally, there are countless variations to this flow, with more or fewer steps, multiple feedback loops, things happening in parallel, and so on.

Moreover, countless questions that fall out from this comparison:

  • Is there a parallel in the world of software to a screenplay?
  • How do the roles in film making relate to the roles of software?
  • Which types of movie productions are similar to the various types of software projects?
  • How are feedback, iteration, and evolution handled in film vs software?
  • Who exerts creative control, assesses market viability, predicts audience acceptance?
  • How is technology changing established ways of working?

I'll explore more of these in subsequent posts, but for now, I'm curious to know if this analogy seems useful. Are there other lessons that can be drawn?