> Not if the developers have basic good practices and understand how to maintain a codebase, which presupposes that they were ever allowed to do maintenance.
I've definitely seen good intentions and supposedly good practices lead to codebases that are hard to maintain. Heck, I've contributed to the problem myself occasionally - and probably everyone has, as that maintenance experience doesn't come out of thin air.
When you look at what the turnover might be at an average org versus how long a system might be used for, it's almost guaranteed that you'll have quite a few cooks in the kitchen, with different opinions in addition to the always changing business requirements and how those might translate to a technical solution.
That said, many of the older languages are actually quite valuable for new codebases as well, because most of the problems that you'll run into have already been solved and the frameworks and libraries are both mature and have proven that they'll most likely be around for the foreseeable future.
I've definitely seen good intentions and supposedly good practices lead to codebases that are hard to maintain. Heck, I've contributed to the problem myself occasionally - and probably everyone has, as that maintenance experience doesn't come out of thin air.
When you look at what the turnover might be at an average org versus how long a system might be used for, it's almost guaranteed that you'll have quite a few cooks in the kitchen, with different opinions in addition to the always changing business requirements and how those might translate to a technical solution.
That said, many of the older languages are actually quite valuable for new codebases as well, because most of the problems that you'll run into have already been solved and the frameworks and libraries are both mature and have proven that they'll most likely be around for the foreseeable future.