What does "build software that can be replaced easily" mean, if not "ensure the abstraction for this component makes sense so that people can replace it if needed"?
Together with your followup qualification of "keep mind of where things need to be focused on efficiency and less on abstraction" I don't understand what you're trying to say at all.
The idea that software needs to be designed to be replaced (as opposed to maintenance/improvement) seems to be very specific to some particular company's organization practices ("re-orgs"). Perhaps my objection to your generic "advice" is that your "it depends" is not "meta" enough to cover the cases where these Conways or whatever re-org crap isn't a recurring thing.
For example, a person who's worked on too many failing projects might advise others to just write crap while looking productive by gaming LoC/commit/bugs fixed metrics, because all projects eventually fail anyway, and nobody cares about code quality if they discontinue the project.
Another person who's stuck maintaining the crap they wrote themselves 10 years ago might go around telling others to make sure you get the first version right so that you don't end up in a situation like them.
I'm not really sure which situation is more prevalent TBH. "It depends" indeed.
Together with your followup qualification of "keep mind of where things need to be focused on efficiency and less on abstraction" I don't understand what you're trying to say at all.
The idea that software needs to be designed to be replaced (as opposed to maintenance/improvement) seems to be very specific to some particular company's organization practices ("re-orgs"). Perhaps my objection to your generic "advice" is that your "it depends" is not "meta" enough to cover the cases where these Conways or whatever re-org crap isn't a recurring thing.
For example, a person who's worked on too many failing projects might advise others to just write crap while looking productive by gaming LoC/commit/bugs fixed metrics, because all projects eventually fail anyway, and nobody cares about code quality if they discontinue the project.
Another person who's stuck maintaining the crap they wrote themselves 10 years ago might go around telling others to make sure you get the first version right so that you don't end up in a situation like them.
I'm not really sure which situation is more prevalent TBH. "It depends" indeed.