Although I’ve mentioned the rope bridge philosophy a time or two, I don’t think I’ve ever written about it, and it looks like the original post over at gamedev.net describing it is long since gone. So here it is:
Imagine that you are a traveler, and you are exploring a new land – one which has many rivers, creeks, canyons, and so on. Often you aren’t sure of which route to take, but you have a general idea of where you are trying to get. This often involves crossing rivers and canyons. Rather than investing the time and money to build a large concrete and steel bridge every time you encounter a river, you first build a rope bridge. This allows you to explore a little further before deciding that you are indeed headed in the right direction.
The idea is to only spend time making bridges that you actually need, and only improving the bridges that you cross often. By doing so, you are able to explore further and faster than if you built ever bridge out of concrete. This also saves you the time and effort of building concrete bridges where such a bridge isn’t necessary. This does mean that, as time goes on, some of your rope bridges will need to be pulled up and replaced with more permanent counterparts. This does involve some waste, but perhaps not as much waste as if you built every bridge out of concrete from the start.
As you gain more experience with exploring, you get a better feel for which bridges should initially be built out of concrete and which ones should only be rope bridges. Again, there is always the risk of building something more expensive that what you need, so if you undecided, it is best to go with the rope bridge.
As you may have guesed, the rope bridge fits in perfectly with programming. Far too often programmers spend time writing code that will either never be used. This may be because a feature get axed or a gets used a lot less often than originally anticipated. It may also be because plans change, or you discover that your initial designs weren’t quite correct. In such cases you’ll want to minimize the amount of loss. By only developing what is necessary when it is necessary, you save yourself any sort of loss. Yes, you may need to revisit code to add more features or improve performance after a period of time, but the time and effort doing so is offset by the time and effort saved by developing features that were never needed.