Code is subject to entropy, as with any complex system, it will tend towards chaos over time.

In this case, as a project move forwards, it becomes harder to maintain order in the code. Deadlines will always push people to cut corners.


You don't have the time to not take the time.

This line was first made when I was a designer. In a project, the producer tried to shovel the game design forward and force the production to start right away while some of the mechanics were not designed yet. In the end, you lose more time if you don't take the time to design and prepare yourself. Others calls it front-loading, but this is mostly said when the production is already underway. I also found it applies pretty well to coding too. Some people want to start coding and want to see result right away. They make bite-sized code block that exist only for a very specific purpose, and any changes will automatically involve code rework. The idea is not to waste your time, but to make it meaningful down the road.

Take the time to decide if it should be generic or specific codes. Generic code can be complex, it doesn't matter because it's generic. Generic code should be shielded against design changes. For example, I've built a camera system that is completely generic.

The design could change a thousand times, I'll never have to rewrite any part of that system. I simply can make every possible camera you could think of, without adding any code. Since it's built in a "lego/data-driven" style, adding a new missing part is a matter of a few lines, and that new lego block can be combined with all the existing one. The system is currently used in 3 different projects, and no new code is needed!

When you decide that you must do something specific to a design request, take the time to understand the GOAL the designer wants. Most designer will express how they think the thing should work, but most designers don't have a code/math background. You have to take the time to decipher the task they want it to perform and to get rid of all the "how it should work". Finally, take the time to analyses the shortcoming of what the designer asked. Is there loopholes? Logic flaws? What the design could ask you to change? What parameters could you expose or create to give him more flexibility, so that if he wants to change something, it may not automatically involve code rewriting? Finally, since it's specific, make it as simple as possible, because it will most likely have to change at some point.

It allows me to keep most of the spaghetti away.