Re: Typically wrong.
"When you build a bridge, it is used that way for decades. What is the last piece of software you have used that is over a decade old without a change? How about 50 years old, we have bridges that are CENTURIES old without a change. It is the changeability that makes software more difficult."
But they are not maintenance free.
Metal-based bridges will get a coat of paint to stop the rust (Paul Hogan's (Crocodile Dundee) day job before he made it in showbiz was, literally, a painter of the Sydney Harbour Bridge).
All bridges, metal, stone or timber get some level of maintenance, paint, replacing rotten timbers, replacing crumbling masonry, replacing rusting beams, replacing footings, pouring new cement, replacing cable-stays, road surfaces, etc etc.
If you exclude feature-releases (which engineered structures also get - spires or antenna added, new lanes, adding or removing a railroad across a bridge, extensions, changing the layout (e.g. knocking out a couple floors to make a 2 or 3 floor high atrium in an existing building)), security patches and bug-fixes are the equivalent of maintenance. Whats the difference between replacing a crumbling stone in a bridge (that stone was too soft for example) with issuing a security patch that plugs a hole?
While I agree that "software engineering" is stretching the definition of engineering, so is saying that engineers build something and it just stays there magically by itself with no maintenance in perfect condition for years, let alone centuries.
Take, for example, the classic, literally textbook, Tacoma Narrows Bridge. That was engineered so well that it'd twist in the wind and be too dangerous to drive across, and eventually, only 4 months after contructed, twisted itself into a complete collapse.
Civil Engineering has had millenia to get it right, and still fuck up big-time. Software Engineering, as a discipline, has only been around for 50 or so years.
Biting the hand that feeds IT
