In Defense of Not-Invented-Here Syndrome

In Defense of Not-Invented-Here Syndrome

One where Joel takes is own life in his own hands…

Seriously, talk about sending in the sacred cows.

If it’s a core business function — do it yourself, no matter what.” – Joel Spolsky

I agree with this and have the scars to prove it. The first debate will be what are, in fact, the core business functions? This is actually a useful conversation to have, even if you don’t continue past this step, because it gets everyone on the same page as to what the nature of their shared endeavor. When making games, one of the early debates always revolves around which graphics engine to use, or should you roll your own. With the advent of mobile, cross platform demands, and the ever rising budgets, there’s been a substantial balance of power shift since this was written.

You see, in 2001, it was pretty reasonable to crush out your own game engine end-to-end. In fact, pretty often it was cheaper to do so because that enabled you to build the production workflow which made sense for your project. Now in 2013, it’s damn near impossible to get a game engine working on all of the platforms available today. In fact, there’s really only a small handful which have succeeded at this (Unity, Unreal, Ogre). And it’s patently a fools errand to try to build a new one. Somewhere, someplace, some producer sort will stop you.

Doesn’t that lead to a relatively homogenous result?

After all, every one is using the same toolchain, and therefore operating under the same constraints. When next year’s version comes out offering, say, cloth physics, suddenly every game has capes.

You see this in the mobile space really clearly. For example, when iOS7 shipped, there was a huge turn and suddenly many apps, which used to be highly customized, reverted to default UX. In my opinion, for the better, but it happened because sustaining that differentiation proved too hard to do over the long term.

It’s one thing to do it once, it’s quite another to do it forever.

That’s the primary way I win these sorts of debates. Yet it’s also the primary way I loose. External dependancies are always the weak link. For anything more complicated that two sticks that your rub together, change is always hard. One tries to insulate the core from these dependancies, but oftentimes it’s just not possible.

Imagine for a moment that the Node.js project exploded. (/points to Open Office & MySQL as case in point.) How on Earth would you migrate to another platform? How would you save that core code? It’s all in JavaScript and there is no other alternative to Node.js of note.

Same thing with cross-platform game engines. What used to be a highly diverse ecosystem has devolved down to two: Unity and Unreal. Pretty damn scary if you ask me.

I’m grappling with this for our dance apps now. There are several choices before me for beat per minute detection. None of them are particularly palatable for various reasons. But I think I’m going to go with the closed sourced solution, because it’s the fastest to ship. You’ll be damn sure, though, that we’re going to write a wrapper around it so we can swap it out at a moment’s notice.

That leads to the corollary:

Isolate all business functions in discrete code blocks, because odds are you’re going to be swapping them out if if you did build it yourself.

(Will need to get more pithy there @ some point.)

“The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it’s botched up.” – Joel Spolsky

Honesty about one’s capabilities is the hardest thing.