Software Upgrades: The Lesson Learned a Thousand Times

Artists and TDs get very excited when they see a launch video for their favorite software, outlining all the cool new features and tricks, previously impossible.  Immediately, they declare that current tasks can not possibly be completed without an upgrade to the new software. Bear in mind, these were tasks that, previous to the aforementioned launch video, seemed to be perfectly achievable.

But techies and artists like to geek out. I don’t blame them. I’m one of them. I've been the artist banging on the manager's door, demanding and upgrade to the latest tools. I was so na?ve.

Advice time:

Don’t. Just don’t. Unless you’re between projects. Or unless there is a show-stopping or other highly compelling reason to do so. Resist the urge. Hold the line. Save yourself, and your crew a bucketload of pain.

I wish I had enough time to write about all my personal experiences that support this advice. I remember switching from one render manager to another mid-project, then walking into the IT office every morning for six weeks to report that no renders made it through the farm overnight, then walking into my supervisor's office to explain there would be no client reviews again today. The previous tool had been working flawlessly. It was old, for sure and soon to be obsolete, but there was no reason to switch right in the middle of a project instead of waiting four months when the project was wrapped. Finally, to get renders done, we had to hire a render wrangler to work 3am to 11am daily and whose only job was to continually requeue frames until they eventually rendered. After spending nearly a quarter million dollars on a new render manager that ultimately could not be made to work, we ditched it for a cheap render manager that worked nearly flawlessly from day 1.

So beware. Every time we upgrade an application, we run the risk of important tools becoming broken, or changing in behavior. You know how engineers love to change things. We risk breaking an established pipeline and having to patch it up, while we are trying to hit milestones.

Cool Features is a terrible reason to upgrade during a project.

Running multiple projects with different timelines? No problem. Your pipeline dept should be able to run a different version per project as you move the studio from one to the other. 

Be patient. Don’t move too fast. Test extensively.  And remember that the most stable software tends to be the oldest. If you want to always use bleeding edge tools, you’re going to get cut sooner or later.