"We should treat software more like engineering projects and design and build it to last."
No, we shouldn't. If you build a bridge to last 200 years, it will remain unchanged for 200 years.
What piece of software can you possibly imagine still be useful if it remains unchanged for 200 years? 50? 10? Hell, can you name a piece of software that was last updated 5 years ago that you still find useful?
Most software becomes obsolete by the changing digital landscape within a year or two if it isn't updated to keep up with the times. That's a major difference compared to physical objects - the physical landscape doesn't change nearly as frequently. That said, we still don't build most physical objects to last 200 years except for the very largest of a projects - and we frequently demo small buidings to put up high rises as the city landscape changes.
Hell, can you name a piece of software that was last updated 5 years ago that you still find useful?
Yes, tons. For example, the firmware for my car's electronic fuel injection (EFI). A lot of software can't easily be updated, or lasts far longer than originally intended.
Treating software development as solely an engineering discipline is, in my opinion, a mistake. That being said, the vast majority of software projects today would benefit greatly from that approach.
Because of your obvious lack of knowledge about "real world" engineering. Think of the planning that goes into just simply replacing the guardrail on a bridge. How are you going to cut it off, replace it, and install a new one on a changing bridge while least affecting traffic? In the case of the bridge I drive over every day the answer was to remove each ~100'x100' section of road deck (there is one in each direction) and replace it in its entirety, one a night, for months. This was to widen the 5 lane bridge by about 3' and raise the guardrail by about a foot. Sure a "minor" revision but I guarantee you could have paid for Flickr and a pile of VC backed startups making a hundred different projects for the cost of having a crews of guys working for months, a barge crane, and thousands of tons of steel and concrete. It just isn't even comparable. Specs changing are a constant fact of life in real world engineering too, they just aren't the #1 issue that has to be dealt with.
I think you're illustrating my point perfectly. An absolutely minor change to replace a guardrail is more expensive "than Flickr and a pile of VC backed startups making a hundred different projects".
Engineering projects do not change frequently and radically. They can't afford to - but more importantly - they don't need to, certainly not at anywhere the pace of software.
A bridge may undergo some changes and facelifts over a 200-year period, but it's still basically the same bridge. But there isn't much software that could last even a fraction that long and not be completely obsolete (without most of it's code getting replaced). In the case of a bridge, the underlying geography isn't going anywhere. That's just not the case with software - even if the platform still exists, the rapid pace of technology means that the software will stop being of any practical use.
A piece of software needs to keep evolving, or it's dead. The same just isn't true of most 200-year engineering projects.
No, we shouldn't. If you build a bridge to last 200 years, it will remain unchanged for 200 years.
What piece of software can you possibly imagine still be useful if it remains unchanged for 200 years? 50? 10? Hell, can you name a piece of software that was last updated 5 years ago that you still find useful?
Most software becomes obsolete by the changing digital landscape within a year or two if it isn't updated to keep up with the times. That's a major difference compared to physical objects - the physical landscape doesn't change nearly as frequently. That said, we still don't build most physical objects to last 200 years except for the very largest of a projects - and we frequently demo small buidings to put up high rises as the city landscape changes.