The question: Which are worse — sequels or remakes.
The answer: It isn’t even close.
Sequels are usually awful, except for direct-to-video sequels, which are always awful.
Remakes, on the other hand, almost always make awful look good. Execrable would describe them perfectly if it were less namby-pamby.
Just look at the remakes of two Dudley Moore movies (but from a safe distance).
Instead of remaking Bedazzled and Arthur (a local reviewer just awarded the latter a half-star out of four possible, with the half-star apparently the result of giving people on the cast and crew jobs in a period of high unemployment) … re-releasing the originals would have cost less and entertained more.
This is just one way movie-making and software development aren’t parallel, as everyone will agree who isn’t nostalgic for green-screen-data-entry/overnight-batch-update-oriented COBOL applications: Replacing an ancient, patched, user-unfriendly batch-processing system with a well-engineered OLTP (on-line transaction processing) application fronted by an elegant GUI is the polar opposite of a Hollywood remake.
Which brings us to the sequel of last week’s interview with Herschell Gordon Lewis, the Godfather of Gore and movie-making project-manager par excellence.
KJR: Where else do you see movie-making and software development as non-parallel?
HGL: Two areas stand out, at least to me as a software consumer. The first is that movies tell a story. That’s very different from the programs I use that have to help me do what I happen to want to do right now.
Another difference: When you build software, you’ll be working with the code a long time. When you make a movie, once you’ve assembled the finished product, everything you used to make it goes away, which is why, when movie-makers build a set, it doesn’t have to adhere to any building codes.
KJR: Beyond what we’ve already covered, what else about the two practices is the same?
HGL: Some film-makers are perfectionists. They might re-shoot the same scene twenty or thirty times to get it exactly right. We worked with a tight budget, which meant the two words you never heard while we were shooting were “Take Two!”
That’s also why I supervised special effects personally. I had a pretty good feel for when they’d be good enough to satisfy our audiences. If I’d had a separate special effects team it could have thrown our production schedule into chaos by concentrating on making a particular effect perfect.
That’s extreme for software: Every time my computer crashes I wish the programmers had a bit more perfectionism in them. But if I was running a software company, I’d want everyone to understand when they’ve reached the point of diminishing returns.
KJR: In our project management seminar we use the phrase, “The exalted state of good enough.” Is that what you’re talking about?
HGL: That’s it exactly.
Here’s something else that also has to do with our movies being business propositions first: We always knew having a finished product didn’t mean we were done. We weren’t done until the movie was in theaters and people knew about it and were buying tickets. We had marketing and distribution plans before we started shooting.
KJR: The parallel, I imagine, is that when a team finishes a piece of business software the work isn’t done until employees are using the new software productively.
HGL: Makes sense to me.
KJR: How about the human equation?
HGL: We worked with a lot of the same actors (using the term loosely) and crew on every movie. It was sort of a repertory company. That meant everyone knew what they had to do without my having to explain it.
Everyone knew each other and how to work together. We left our egos at home. We had no prima donnas, and nobody had anything to prove.
Everyone showed up on time. When we were setting up in a location, everyone carried cables and equipment, everyone helped set up the lights, and everyone helped carry our main camera (it weighed roughly 16,327 pounds so we needed everyone to pitch in).
When we were finished at a location, everyone helped clean it up and haul the equipment back to the van, no matter how late it was, because everyone understood, that’s how we did things. We finished each day’s work that day … no exceptions … and we weren’t finished until the van was packed and loaded and the location was pristine.
KJR: Keeping teams together. What a concept! Anything else?
HGL: Well, I wonder if your subscribers would be interested in the time you …
KJR: Gee, what a shame. I’d love to explore that, but we’re out of time, and room.
I like the idea of “good-enough” in software development, but in reality software developer are often not satisfied with “good-enough” because their egos are at stake in the game. So “polishing the apple” is more than often what they do. We want to find all the possible “bugs” that might be lerking under some rock unturned, but when is enough? Software quality has long been a subject of students and professors of the software development game and defining “quality” is really what’s at stake. But often quality, and time (which equates to cost) are on an inverse scale and when push comes to shove, costs and/or time wins out. When is “good enough” good enough is the question and how does one determine that “when” as it translates to cost and a servicable software piece of work well done.
“Keeping teams together” is pretty much an alien concept when programmers and software engineers are fungible (thanks for teaching me that word Bob!).