An elephant vs. the porcelain factory

Lately I’ve been working on modifying existing games for a new customer. Each game packs a couple of years of codebase history, one of them even has had multiple developers assigned since its birth.

Now, let me start by stating that I’ve never considered myself especially gifted when it concerns programming. I know my way around the fundamental concepts, and pack a decent analytical skill when it comes to design and architectural decisions. But these recent work tasks as really challenged me in almost all dimensions.

Getting to grips with the original mental model of an application is indeed much more complicated than understanding the problem domain itself (ahem…depending to some extent on the problem domain type…). Unfortunately there is very little documentation related to the games I have been working with. Most application knowledge exists within the head of the firm’s game grandmaster. Luckily he is very friendly and willing to help.

But as the title of this post states, it is easy to feel a bit like an elephant in a porcelain factory. Whenever you have to make a turn, your large behind knocks over something fragile and hard to recreate. So You learn to turn very carefully, and perhaps even get a little paranoid and do nothing but tiptoe around all day. When working within a fixed iteration with defined tasks and deadlines, a though choice have to be made. To continue building on top of existing code trying not to break anything, or to acquire the appropriate resources for rebuilding the program, knowing that it most like would not be backwards compatible and we would end up with parallel codebases for the same application (more or less). I guess that abstraction and modularization would cure some of our difficulties, but such rework would still require unavailable resources.

I guess communication is the golden key to success, once again.