Anthony Bailey ([info]anthonybailey) wrote,
@ 2004-10-17 02:08:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Current mood:uncertain
Entry tags:machinima, software_development

Film-making and software engineering
Film-maker [info]cairmen posted recently comparing their current phase of production to bug-fixing in software, and wondering about analogies between his world and that of software engineering. And the other week after watching DVD extras for The Fifth Element, the lead programmer where I work (Dave Turner) said he thought he saw interesting correspondences between working on a film and on a software project. (In particular, he thought said film showed an unusually strong core vision and emergent realisation compared to some other blockbusters, and when tonight I happened on this related note re agile software development and film, it kicked me into this update.)

I'm always inclined to be a little suspicious of analogies between the two worlds since I always hear them made by those with significant experience in only one of the two. Like most software engineers, Dave may watch films, but he doesn't make them. And although the massive importance of technology in the machinima medium within which [info]cairmen works means that his outfit Strange Company have been involved in writing some software, I believe that he remains some distance from having a good view of what software engineering on a medium scale is like.

Of course, the fact that people on both sides posit the analogy is highly suggestive, so I would be interested to see it explored some.

Definitely in both cases we have a moderately sized team of people working together on a project with an eventually inescapable time/resource budget to produce a creative work that will be judged by a target audience whose exact desires are very hard to quantify in advance. Also it helps to have a core vision, you learn a lot as the project progresses and benefit if you can take advantage of that, and the only possible response to the inevitable over-runs is to try to cut "features" without wrecking the entire proposition.

So, you would expect analogies.

But I do think that the facts of real life mean that the above properties will hold for very many collective human creative endeavours, so maybe software and film are just two that the pair happen to have a vague awareness of. The worlds do also have some pretty major differences: an obvious one is that (jokes about generic sequels aside) you only really release a film once, whereas software goes through many versions - so postproduction maintainence is much more important. And I struggle to imagine useful analogies on a lower level (what is unit-testing for film? Or refactoring? Or software architecture?) although I grant that this could well be because I also lack experience of film.




(7 comments) - (Post a new comment)


[info]cairmen
2004-10-18 05:29 am UTC (link)
Refactoring - in film is vital. Making sure that there are no redundant elements and that the architecture of the film is as elegant as possible are vital in several stages of production, most notably around focus-group testing before release.

Architecture - I'll ask [info]zornhau over here to comment more on this, but I think that there's a very definite advantage in film to preparing the architecture of the project as thoroughly as possible before you even get to the script stage - see Robert McKee's "Story", where he posits an architecture of story that can be used to underpin any writiing project.

We should chat about this more - perhaps I should ask you to get involved in our story planning meetings to see how it looks from a software engineering side.

(Reply to this) (Thread)


[info]anthonybailey
2004-10-18 04:08 pm UTC (link)
I think your understanding of the terms in question with respect to software engineering may be incomplete.

For example, refactoring is improving the internal quality of the code used to implement a particular program (a "user experience") in a way that is invisible to the user. If a change results in a difference you can see a difference from the outside, then by definition it wasn't a refactoring.

I can get mileage out of that kind of analogies only if I match the software product as experienced by the user against the story being told rather than against its "implementation" as a particular film. This may not be a bad analogy, but it is a rather non-obvious one. It would seem more natural to expect the deliverables being worked on to match - i.e. the movie product maps to the software product.

Software Deliverable as Story (and Code as its Realisation) brings up some other possible analogies (e.g. coding in a different language becomes retelling a story in a different genre altogether - prose, theatre, etc.) but it breaks a lot of others (e.g. what does visual design of a software product now map to?) and on the whole I find it confusing - what does the hundred minutes of footage I would call a film end up mapping to in the software world?

I'm not averse to the chat though - perhaps I am misunderstanding some of the fundamentals of film-making, perhaps a set of inconsistent mappings between smaller sections of the worlds still gives some useful insights.

(Reply to this) (Parent)(Thread)


[info]cairmen
2004-10-19 03:47 am UTC (link)
Yep, that was my understanding of refactoring.

I guess the analogy I'm making here is that while the changes made in editing might not be unnoticable to the viewer, they will probably be close to undetectable unless said viewer is trained and watching carefully. After a pass by a good editor, an untrained viewer might spot a couple of the biggest changes, but will mostly just feel that the film was "faster" and "smoother". They'll probably not even be able to tell you why that was.

(Reply to this) (Parent)

Hmmm
[info]zornhau
2004-10-26 01:37 am UTC (link)
Having been involved in both, I think there are similarities between coding and film/fiction projects, if only because they are both creative projects (in the broadest sense of the term).

If the results of "refactoring" can't be visible to the user, then you can only apply the term to film/fiction if the deliverable is the high concept as it arrives in the user's head. Not sure how useful this is.

There are certainly other analogies for fiction which I think may also apply to film:
analysis - working out how to deliver the high concept to the target market
architecture - outlining and bible
unit-testing - workshopping a section (test screenings for films)
prototyping - rough draft (previsualisation for film)
marketing - marketing

(Reply to this) (Thread)

Re: Hmmm
[info]anthonybailey
2004-10-29 04:17 pm UTC (link)
I mostly admit your analogies, but unit-testing is the automatic reverification of the behaviour of small components of the software system: the interaction level is mostly below the radar of a user. User-testing might be a better analogy to the test-screening, perhaps.

(Reply to this) (Parent)(Thread)

Re: Hmmm
[info]zornhau
2004-10-30 04:51 am UTC (link)
Agreed. I think this search for analogies might point us to general truths about creative projects, but otherwise it's not very useful because we're trying to map two very specialised activities.

For example, to take another activity: I can see the similarities between my take on effective plotting, and the 15th-century writings of Miester Liechtenhauer on the Longsword.

Miester L identifies five Master Strokes chosen from many possible strokes, as being the effective ones.

Similarly, I'm begining to suspect that there only a limited number of effective scene structures.

However, this just shows that the 80/20 rule applies to both fighting and writing - a pleasing thought which makes me feel more macho (until somebody points out that it also probably applies to golf, ballet and macrame...)

This is a fun parloud game, though. What about analogies between, say, computing, writing and cooking?

(Reply to this) (Parent)


[info]anthonybailey
2005-07-12 12:26 am UTC (link)
[info]cairmen provoked me into further exploration of the view that the best analogies probably emerge at the project management level rather than the engineering level when he made this later entry on the topic of project planning.

(Reply to this)


(7 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…