The rope bridge philosophy is something that I discovered over at GameDev.Net a long time ago, so I can’t take total credit for it. It goes something like this:
When you need to cross a river, you first build a rope bridge. You don’t start with a concrete and steel bridge, because you don’t know if you will be crossing over that same river again. By starting with just a rope bridge, you’ve spent minimal resources on a problem that you aren’t guaranteed to encounter again. If you find yourself needing to cross that same bridge multiple times, then you can go and revise/rebuild the bridge with something stronger. Yes, it means you’ve built the same bridge twice, but you’ve also saved yourself resources by only building what is necessary.
This is totally applicable in programming – especially something like game development. There is often no clear “best” solution, and you face a huge number of unknown problems. You don’t know if the game you have designed is going to be fun without getting something working first. You only want to spend resources where they are going to matter.
Eventually, as you gain more experience, you learn when to preemptively built a bigger bridge. Like anything else, a bit of that intuition comes from experience. But even then, you still risk the danger of spending resources where they won’t be needed.
Something that I often tell my team is the following:
1. Make it.
2. Make it work.
3. Make it work right.
4. Make it work right fast.
Building a bigger bridge before you’ve gotten to your destination is making something work right/fast before the entire thing works. Learning when to build something bigger than a rope bridge at start is a bit of an art. It takes experience – but experience only comes at the cost of making mistakes. You also need the freedom to go back and revise/refactor things once everything is working. This is something that you often have to push for, and something that management needs to understand.