Alan Cooper presents the analogy that software development is like making movies in his book, The Inmates are Running the Asylum. [This is a fantastic book for getting an understanding of exactly how Cooper’s perspective evolved over the last decade.] Cooper is presenting the analogy in the context of validating the business case for investing in interaction design.
Cooper points out that they’ve been making movies for a lot longer than we’ve been making software, and he’s exactly right that there is something to learn from the film industry.
How the movie industry works
The movie industry manages movies in three phases:
- Pre-production. Determining what the movie will be about, raising funds, storyboarding and designing the movie, getting actors signed, writing the script, etc.
- Production. Shooting the film. Directors, actors, and crew all working very expensively to get the film shot.
- Post-production. Tweaking and finalizing the film.
How software development parallels movie making
Software development involves three phases as well: Decide what to do, do it, and deliver it.
The interesting thing to note is that the film industry universally invests time upfront in pre-production, to minimize the costs of production. They recognize that production is more expensive than pre or post-production. Many software teams take the same approach, although Agile development explicitly does not. We gleaned some insight into Cooper’s perspective from our coverage of a debate between Cooper and Kent Beck.
If we accept Cooper’s premise that production is more expensive than pre-production, then software should follow the same model.
It’s worth noting that an agile process results in more design, not less. Beck might argue that redesigning as we go is less expensive, because we improve our ability to understand what we actually want to create during the process of creating it. Cooper disagrees.
As much as we like Cooper’s insights, the movie cost structure is not paralleled in the software development structure. When we hire developers, it is analogous to the old movie studios keeping actors on retainer – the cost is “fixed.” And the infrastructure costs of production (set creation, for example) are not affected by the time spent in production – they too are fixed. If we have a project with contractor developers, then we have a variable cost, and we lose money while those developers are “sitting around.” However, today’s projects leverage outsourced overseas contractors more and more – and these actors are a lot cheaper than script writers.
What we know in spite of the analogy’s flaws
We absolutely save time and money by defining requirements before we write the software. We also know that it is important to design before we code.
Neither of these statements conflicts with agile philosophies, if we take the approach of treating “design everything” with “design this one thing” similarly. An agile approach will simply have multiple design/implement cycles, each focused on a subset of the software (and allowing for a redesign phase prior to delivery).
I suppose the big problem with the movie-software analogy is that the views of the end user in movies tend to be very varied. Very few movies manage to please the majority of people and their expectations even when they are the intended audience…
Hey Rich, thanks for reading and commenting!
I had to reset my “who are the users?” perspective when reading Cooper’s book. He contends that while there may be several users (personas) who use the software, you must design it specifically for one or at most two primary users.
He points out that you can’t be all things to all people, you end up with a homogenized application – either watered-down to the point of uselessness, or bloated-up to the point of frustration for all (all except other programmers, that is). I think he’s exactly right.
Some movies try to appeal to cross-over audiences (a fight scene in a love story) to get economies of scale. The fight scene is unappealing to the moveie’s target audience, and likely not enough for the cross-over people. Great movies stay true to their audiences and don’t cross over at all.
I’ve come to realize that the same holds true for software. “Universal appeal” should never be a goal for most software.
Some problems with the “software-as-movie-production” analogy:
1. Movie projects are even less successful on average than software projects.
2. Most successful movies are the result not of a requirements gathering process, but of an auteur’s vision (Chinatown, for example), or the vision of a handful of people (Casablanca).
3. In today’s market, a huge part of the overall budget of a movie is pre-release marketing. A blockbuster, with a production budget of $100 million, will often have a $40 million marketing budget. There’s simply no analogy in software products.
Bottom line, the whole relationship of the production to the user/client is completely different between software and movies. The point that movie makers spend a huge amount of time on pre-production (although a relatively small amount of their budget) is excellent, but I don’t think there’s too much more to learn from the analogy than “figuring out what you want to do at the beginning of your project is a good thing.”
If it is necessary to make Cooper’s analogy fit Agile then its worth bearing in mind that Agile development often has phases. In XP for instance before code written both the exploration and planning phases are performed. However deciding what to do, doing it and delivering it do not advance software process much. You just end up stretching the semantics of each to make it fit. For me where these analogies are useful is to affect a change in emphasis. The idea that software is like the movie industry evokes a different way of thinking about product design; a way of thinking that is better suited to interaction design. However if you are in the guts of the system debugging a very intricate issue, another analogy might be best fit. It seems to me such analogies are used to get people thinking along the same lines, not to suggest that one model should fit all. From one role software might look like a film, from another role it looks like something else. Reminds me of the story of the blind-men and the elephant.