Should We Build Movies Like We Build Houses?

Lately I’ve been thinking about the screenplay as a kind of software and have turned to certain software development processes in search of models for alternative methods of screenplay development (particularly for microbudget features). I see many commonalities between programming and screenwriting (“A computer script is a list of commands that are executed by a certain program or scripting engine” [], while a movie script is a set of instructions that must be executed by a cast and crew), and I believe screenwriting quality and efficiency can both be improved by incorporating innovative strategies from the world of software design.

Mainly “software” seems an ideal 21st century alternative to the “blueprint” metaphor in screenwriting discourse. The software metaphor opens screenwriting up to new levels of interaction, iteration, collaboration, and improvisation — harnessing collective intelligence, rich user experiences, and perpetual beta. It was with some amusement, then, that I stumbled upon a recent editorial in WIRED by computer scientist Leslie Lamport, in which he argues that software developers need blueprints:

Architects draw detailed plans before a brick is laid or a nail is hammered. Programmers and software engineers don’t. Can this be why houses seldom collapse and programs often crash?

Blueprints help architects ensure that what they are planning to build will work. “Working” means more than not collapsing; it means serving the required purpose. Architects and their clients use blueprints to understand what they are going to build before they start building it.

At first blush, Lamport’s argument would seem to contradict my proposal for a more open scripting practice in feature filmmaking, but in fact, Lamport manages to make the comparisons between software programming and screenwriting all the more apt while reinforcing my argument for flexible script forms. “[F]ew programmers write even a rough sketch of what their programs will do before they start coding,” he writes (emphasis mine).

What do I mean by a specification? It is often thought to be something written in a formal specification language. But formal specification is just one end of a spectrum. We wouldn’t draw the kind of blueprints needed for a skyscraper when building a toolshed, nor should we write formal specs for most software. However, it’s as silly to write small programs without writing specs as it would be to build a toolshed without first drawing some kind of plan.

Lamport’s point is that “Blueprints help us think clearly about what we’re building,” but his definition of a “blueprint” for programming is already far more flexible than a literal blueprint. Creative laborers need to plan before they work, but the plans may take many forms. In feature filmmaking, the skyscrapers (big budget Hollywood popcorn flicks) may require formalized blueprints (a conventional shooting script), while the toolsheds (microbudget independent features) may require only rough sketches (an outline, etc.). Planning is the universal principle. The shape of the plan is dependent on the needs of the project.

Permanent link to this article:

Leave a Reply