Category: Software Engineering

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.”