| >We don't always have the engineering tools to predict strong "wear and tear" models of such things in software like civil and mechanical engineers have for common bearings/gaskets/lubricants Because it's not wear. Wear can be measured. Wear is predictable. This again comes back to the mental model. >most modern OSes now experience major changes once every 6 months, often with alternating (1 year) "LTS" releases For the OS, this is a fair point. Maybe it should be mandatory to plan for OS updates, which often cause a host of issues. >some ways the software industry still maybe needs more of a better defined engineer/mechanic split than it has today I think the reason we don't have a proper split here, is because a split here isn't really possible. Maintenance work _is_ engineering work, you need good judgment to decide whether a dependency update is ok. A proper test suite can help make the maintenance easier. But there's no mechanic equivalent, since there's not necessarily modular parts to be replaced when interfaces change. I think all in all we need to move away from engineering analogies. SW engineering is different enough that these analogies do more harm than good. And in the end we should have the self-confidence to ask our managers to understand software as its own discipline. If a manager doesn't understand what they're managing without heavy-handed analogies, they are in the wrong position. |