The Niagara Falls Supension Bridge Programming Analogy

So much for the title. But this story has been stuck in my head since my childhood.

Well, the story goes that in 1848 it was decided that a suspension bridge had to built across the Niagara River. People were tired of taking the long way around. But this bridge was being built in the most turbulent part of the river. A boat could not make it across.

So the solution was to start with a kite. The bridge company held a contest that paid five dollars to the person who could get a kite across the river first. Once the kite was across, they could use the kite string to guide a small rope across. Then the same process for a thicker rope. And finally a cable.

And this has always been the way I have written software. Get that thread across first. Don’t worry about features. Don’t redo the same menu 5 times when the application doesn’t even save records correctly to the database yet.

Figure out the least amount of functionality you need in your application and start with that. Use the default theme in your framework or component package and make it work. Or you just might never get there and at the very least, you’ll slow the whole process down.

Then you add a little more at a time and try to keep functionality balanced across the application as you go. Every application is unique in one way or another. Even if you use a framework to build it, your application should have it’s own framework. It should have a design that fits it’s use.

You have to see the application as a whole to be able to do this. You will have to look over the project and find the best place to put that first string across. And from there add more to it’s structure from the inside out.

This keeps your application from being lopsided. From different patterns being used in different parts of the code. Modularity is a great way to add features once you have a robust application, but in order to make modularity possible you have to have a stable stucture to handle it.

I had to actually look up the story to make sure it was true after I wrote this post. It turns out it is. You never know. So many things I was told when I was a kid turned out to be untrue and it wasn’t as easy as checking Wikipedia. But even if it was false, the analogy has helped me build more robust applications and finish projects.