I can remember a time, not too long ago, where Epic was in a very public dispute with Silicon Knights, the developers of Eternal Darkness and Too Human.  From the beginning, it seemed a bit silly to me.  I mean, they knew what they were purchasing at the time of sale, so why all the fuss?  Well, I have recently learned that you don’t have to look beyond your own company to see the same kind of bickering.

Recently, I have been spearheading an effort at my job to create a centralized technology.  It grew out of my frustration over the thousands of wasted man hours, and ludicrous levels of over-staffing that have occurred.  A popular phrase over the last 9 months has been, “we just don’t have enough engineers”, but then I overhear countless discussions amongst the engineering teams that involve a re-architect of code that already works.  Many times, the discussions revolve around the same segments of code, and go through an annual renewing that often cycles between the same 3 design philosophies.  No one has been on these teams long enough to realize that they are introducing the same mistakes that were resolved 2-3 years ago, and thus the cycle continues.

The primary culprit of this viscous cycle was a Massively Multiplayer Social Training Simulation (MMSTS?) that has been in development for about 4 years now.  Unfortunately, it has suffered from a “changing of the guards” on an annual basis; leaving a new Lead Software Engineer who swears that he/she knows the best way to re-invent the wheel.  As expected, the project hasn’t gotten very far and other technologies within the company have long exceeded the capabilities of that game.  In addition to all of this, other projects within the company were solving the same problems, if not more.  It has now resulted in an excess of personnel that is easily 40% or more.  That is what I had set out to resolve.

I had finally convinced the executives to allow me to take the best of breed technologies that were developed, from more successful products, and create a centralized engine, something that could handle about 70-90% of the type of projects that came through the company.  Being a super-set of anything that was required for the MMSTS, I figured that it would be a cakewalk to convince the teams to use it…

Before distributing this new technology, it was field tested on a couple smaller projects and passed with flying colors.  It is now being used on a new MMSTS that is Web 2.0 compatible and is maturing with each success.  The engine was designed to be a simple toolkit; dropping assets into a folder and writing a couple scripts.  Entire training applications could be written without touching a line of C/C++.  When presented to the original MMSTS team, it only took a day or two before they started to schedule meetings about what pieces of code needed to be changed, and re-written.

It only took about a month before they started to have merge conflicts between their branch and the engine’s trunk repository.  Eventually, I had to make it clear that I could not support the team if they made drastic changes in architecture.  I’d like to think that the point was made, and they could just say, “thanks for making my work-week 20 hours”, but it seems like no Engineer will ever be happy with a line of code that he didn’t write himself.

I’m sure you all have similar stories to tell.