Category: Games

Hacks and Rewrites

This summer, the team I am working with decided to reuse our engine from the game Project Albatross and upgrade it for our current title, Soul of the Machine. This resulted in some discussion regarding hacks and rewrites. As we approached the deadline for Project Albatross, several small but stable hacks crept into the engine. Now that we are back in development, we have been able to rewrite code and remove inelegant solutions. Two things were learned from this experience: (1) hacks are not always bad, and (2) never rewrite a system from scratch.

As a Software Engineer, I like code with elegant architecture and purposeful design. Unfortunately, beautiful code takes time. Sometimes it takes longer than the time allotted for a project. As a result, ‘hacks‘ are introduced into beautiful code bases to address issues before a deadline. This is frustrating but not necessarily undesirable. If a stable hack delivers required functionality on time and does not endanger the future architecture of a project, it is not necessarily bad. Recently, I watched Vijay Thakkar’s GDC talk about the scaling issues encountered in Zynga’s Words with Friends. It is worth a watch and he states a similar acknowledgment that not all hacks are bad.

When inelegant solutions creep in, the desire to completely rewrite a code base increases. It is important to note that a lot of knowledge will be lost if this occurs. As Joel Spolsky, co-founder of Stack Exchange, states in his article Things You Should Never Do, Part I, “When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.” It may be difficult to rewrite code so that inelegant hacks turn into well-structured features, but it is not worth throwing away an entire program to start from scratch. We learned this as we re-factored the engine for Soul of the Machine. It took less time to re-factor hacks than it would have taken to rewrite the engine. Even if you are convinced that a software project needs to be entirely rewritten, Joel Spolsky makes another great point. “It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.”

Production Priorities

(Warning: These thoughts are based on my experience and I will attempt to never assert anything I write as fact. Many of these ideas may be in contradiction to the practices of successful teams. I believe every team needs to find its style of work to be most productive. These are simply my thoughts based on previous experience.)

Production is a balancing act. I find myself walking a fine line between guiding work in a specific direction and ensuring people have the freedom to work on what they desire. Without autonomy, I easily lose interest in my work, and I believe this is true for most individuals. However, without some traffic direction, autonomous work among many may not coalesce into a cohesive whole. There exists a continuous struggle to find balance as a Producer. It is easy to become what people call a “micro-manager” by planning out all the details of a project and how it should be accomplished. I believe this hurts a team by not providing people creative freedom to do their job. On the other hand, it is easy to not manage at all, resulting in ideas that never form into a final product. Therefore, I try to walk a fine line between these two extremes. I attempt to give team members the freedom to work as they see fit, but I sometimes encourage they work in a specific direction.

Since I am writing about people, here are three priorities I follow in Production.

  1. My first priority is always the safety, health, and happiness of my team members. I care about each individual on my team, and I want to see them succeed. The moment team members become tools for getting a task done, their maximum potential is lost. There is no reason for them to respect a Producer who treats them as such and no reason for them to care about what he/she says. It is important to invest in human beings and take interest in their success.
  2. I want to give my team members whatever they need to succeed. Maybe that means I have to connect them with the right individual to answer their questions. It could mean I need to hold a meeting so that ideas and intent are fully communicated. Maybe I cancel a meeting so they can get work done. At the very least, I should start bringing donuts and Nerf guns to team meetings. Whatever my team needs to succeed, it is my job to make sure they have it.
  3. I must meet a production schedule on time, within budget, and at the promised level of quality. If I take care of my first two priorities, this third is usually much easier to accomplish. Future posts will cover some thoughts I have on project management techniques.

I believe Production is first and foremost about people. When a manager does not care about the members on his/her team, they will lose the amazing talent that team has for creating enthralling game experiences.