I recently read an article detailing the many “production woes of the rather unimpressive 1994 Street Fighter movie”:http://www.polygon.com/features/2014/3/10/5451014/street-fighter-the-movie-what-went-wrong. At the time — given the cast, director, and writer they’d lined up — it seemed like a promising property. Writer/Director Stephen de Souza had been responsible for some of the most iconic 1980s action movies, and they’d also managed to cast noted actors Jean-Claude Van Damme and Raul Julia.
In retrospect we know how badly all that promise was squandered (if we remember that movie at all), but when I read the analysis of exactly how it all went wrong, I was struck by just how mundane and familiar their issues were: changing requirements, tight deadlines, shifting schedule and priorities.
In other words, all the same things that seem to plague doomed software projects.
h2. Changing Requirements
Capcom owned the Street Fighter property, so if the movie was to go forward, they’d need to be on board. One of the very first things de Souza did was to select which characters from the game would be in the movie and to cut the list down to a manageable number. He managed to sell Capcom on 7 characters.
…Until they changed their minds and added 2 more. And then 2 more on top of that. Eventually they made it up to 15 characters — leaving approximately six minutes of time on screen for each character. That is not exactly optimal for storytelling.
How many times have you been on a software project where they “had to have” feature X — no matter how much it complicated the interface or data model?
h2. Tight Deadlines
The producers started assembling a team in mid-1993 and managed to get a chance to pitch the project to Capcom. However, Capcom needed the movie to be out for Christmas 1994. That’s a bit more than a year to write, cast, shoot, edit, and market a film.
So many software projects have inflexible external deadlines too: legal deadlines (such as for Healthcare.gov), conference or trade show dates, fiscal year boundaries, or other concerns.
h2. Shifting Schedules
They’d planned a schedule early on that would allow the stunt coordinator time to choreograph, rehearse, and shoot scenes. However, Raul Julia’s failing health forced changes in the schedule, so scenes were shot out of the planned order. This meant the actors weren’t trained to perform the stunts safely, so things looked sloppy or had to be simplified.
On my projects it always seems like no matter what sort of ordering we start with, we find out that there’s a dependency we didn’t know about, or that we don’t have the right access to the production system, or we need to wait for a purchase order to get approved.
h2. Software Projects
Too frequently software projects are compared to other engineering projects: “If bridges collapsed as often as my computer crashes…” But that isn’t a fair comparison, because building software isn’t like building a bridge. But maybe building software is like making a movie.