The only issue with your second point is that it can eventually become a quagmire when you do need to upgrade it.
I work for a very old company who held to that philosophy for many years. And while any individual component could be looked at and seen as running fine, when they did finally decide it was time to upgrade they were faced with needing to upgrade everything simultaneously.
All of the tech was too old, so no current tech had the sort of backwards compatible bridge that helps you move forward. It’s like figuring out how to get your telegram system to also work on your WiFi network, nobody makes any interfaces for that.
Instead of slowly and gradually replacing components over time, they’re faced with a single major overhaul that’s put the entire company at risk because they have to completely shut down for over a month.
I added “foreseen in the near future” because of thinking along those lines but in all fairness there isn’t really a clear point were the risk of being stuck becomes a such “need” due to “foreseen in the near future problems”.
What I’ve seen done is developing a whole new system in parallel with using the old one as it’s usually significantly easier (and less risky) to reverse engineer the functional and business requirements for the new system from what the old system actually does that it is to get try and put them together from what people think they want, as they are seldom aware of the nitty-gritty details and tend to have only a view of the perfect world usage of the system and not at all of the “what if somebody makes a mistake at this stage?” human error conditions that the system must handle amongst other issues - or in other words they generally “only know what they want when they see it”.
But yeah, that point of mine does relly on quite a vague judgement: it’s better than pursuing what’s new for being new but it’s not a clear actionable rule.
The only issue with your second point is that it can eventually become a quagmire when you do need to upgrade it.
I work for a very old company who held to that philosophy for many years. And while any individual component could be looked at and seen as running fine, when they did finally decide it was time to upgrade they were faced with needing to upgrade everything simultaneously.
All of the tech was too old, so no current tech had the sort of backwards compatible bridge that helps you move forward. It’s like figuring out how to get your telegram system to also work on your WiFi network, nobody makes any interfaces for that.
Instead of slowly and gradually replacing components over time, they’re faced with a single major overhaul that’s put the entire company at risk because they have to completely shut down for over a month.
True.
I added “foreseen in the near future” because of thinking along those lines but in all fairness there isn’t really a clear point were the risk of being stuck becomes a such “need” due to “foreseen in the near future problems”.
What I’ve seen done is developing a whole new system in parallel with using the old one as it’s usually significantly easier (and less risky) to reverse engineer the functional and business requirements for the new system from what the old system actually does that it is to get try and put them together from what people think they want, as they are seldom aware of the nitty-gritty details and tend to have only a view of the perfect world usage of the system and not at all of the “what if somebody makes a mistake at this stage?” human error conditions that the system must handle amongst other issues - or in other words they generally “only know what they want when they see it”.
But yeah, that point of mine does relly on quite a vague judgement: it’s better than pursuing what’s new for being new but it’s not a clear actionable rule.