Surely building software should be like building railroads

My friend, Steve and I were discussing project management over lunch. He left me with a wonderful gem. Since he doesn't blog, I'll share it here.

Imagine you were building a railroad and management wanted a timeline. So you diligently look at the costs of building the trains, the train stations and the railroad etc. and come up with a cost. Armed with the data based on all your years of experience, you're present this to your management team and board of directors only to be told it is not good enough. They need it much faster than that. You're told you have to be more innovative in your thinking. Here are some of the recommendations that were offered at the meeting.

Take an existing train and make it work on the track even if the track gauge is different. Can't be too hard, they all work the same way.

Don't wait for the seats to arrive. Passengers can stand for the first few months. We'll put them in the next time the trains are serviced.

Don't test the train or the signalling system. We could cut our launch date by several weeks. Better still, let our passengers tell us what's broken.

If the railroad is taking too long build, remove some of the tracks thereby saving materials and labor.

Don't advertise the timetables to save publishing and marketing costs. We'll spread the word virally by using our passengers.

Train drivers are too expensive, I have a cousin who's looking for work and he's pretty cheap. I'm sure he has friends too.

The point is we don't build railroads or airplanes that way. So why do we consistently do this in the software world. Beats me. Do you know?