"Have you ever ninja'd a feature into a product you were working on?"
I looked at Kris blankly after he asked me this question at dinner tonight.
"Have you ever put in a feature into your code that wasn't in the spec[ification], but that you wanted in?" he reasked.
Ah.
I smiled, and immediately began thinking of the various features I had, indeed, put in various programs I've worked on, features that weren't in the specification, but, darn it, they should have been. After looking at him with a huge grin on my face for a show while, with his wondering exactly which feature I was going to reveal first, I finally said, "Sure! A D B create."
He laughed.
When I was working for PDI, now PDI/Dreamworks, I wrote a program called adb_create. The adb part stands for "Animation DataBase," and was PDI's proprietary format for specifying animation data. I worked as a Lighting Technical Director, which meant I was responsible for dealing with the technical issues of the lighting department. Well, I and the other TDs who worked with me.
As the Lead TD, I also worked with the surfacing department, who created texture (and other types of surfacing) maps for the models for various computer generated films (in particular: Antz and Shrek).
One of the incredibly (more so that it should be) difficult tasks in the surfacing department was generating correctly sized base image files that would be wrapped onto the models. The programs that were in place were old, unmaintained, difficult to use, and quite error prone. Since the task was so difficult, I set out to write a program that WOULD actually run correctly, generating accurate files for surfacing artists to start with for surfacing models.
Now, at this moment, I need to mention that PDI had an R & D department. This department had "real" programmers: the women and men who worked with vertices and deep files and ray tracers and motion interfaces and oh, the whole bunch of complicated software, written in C because of a particularly bad rewrite years before in C++ that made everyone in the department decide object-oriented programming was evil, when in reality, just the implementation was evil.
Beside the point. The point was that R & D had their CVS repository and their install directory that no one outside R & D was allowed to commit to or deploy in.
The rest of the programmers in the company were "light" programmers, using whatever tools we had handy, existing or written on the fly, to get the job done. We weren't interested in necessarily the best solution, but rather the one that worked now with least amount of effort, because the scene, shot, feature, effect was due, and we needed to get it done. Now. No, yesterday.
Well, adb_create actually fit into the R & D tools. It was named as those tools were (prefixed with adb_). It was written in C as those tools were. It used the libraries that those tools used (you know, the ones R & D wrote and supported).
So, I deployed adb_create into the R & D directory, before integrating it into the surfacing workflow.
And received all kinds of uproar in return.
The worst of it was from my roommate, Dan Wexler. Dan was the lead developer for the company's renderer. He was The Man in the department. If he fell off a cliff, well, they had key-man insurance on Dan.
Dan had heard about how crappy the various surfacing tools were. Actually, he had listened to complaints from the surfacers for years, on how bad the tools were for them. Modelling had its own R & D developer. Lighting had several R & D developers. Heck, so did the animation department. But not the surfacing department, and, boy were their tools sucky.
So, Dan came up with this wonderful (or so I was told) plan on how to fix the surfacing tools. It involved several rewrites of various libraries, integration with a few existing tools, and a whole lot of effort in the R & D department. So much effort, it turns out, that the plan was put on hold until these other, more important, features could be completed.
On hold.
For years.
Along I came, and, tasked with fixing lighting tools from the production point of view, I fixed the problem. I wrote the tool that surfacing needed. I gave them adb_create.
By doing so, however, surfacing stopped complaining.
And by stopping the complaining, I thwarted Dan in his desire to see his new plan implemented.
And we entered into a long, downward spiral of arguments.
He wanted to implement his plan, but he needed surfacing to complain loud enough for those who set R & D's priorities to schedule time for the plan to be implemented. With adb_create, they stopped complaining, and his great grand plan would never be implemented.
I countered with the fact that I needed these tools to get the job done with the current workflow. I don't care about the great, grand plan, I needed to get those models surfaced and in the lighting shots now, not next year. Without adb_create, the surfacers had to work ten times as hard (well, ten times as long, and I'm not exaggerating on that number) to finish their work. I didn't care about next year, I needed results now.
It wasn't until Richard Chang, one of PDI's cofounders, stepped into the arguments and said, yes, it should be deployed to the R & D sacred directory, that the arguments finally ended.
I left PDI soon after that fiasco. I don't know if Dan's grand plan was ever implemented. Last I heard, he had oved to Tahoe, worked part time, gotten married to high school (college?) sweet heart Emily, and eventually left PDI.
I also don't know how long adb_create was used at PDI.
It is, however, my greatest ninja'd feature.
