Re: "Quality" is a structural attribute, not a bolt-on
Me: "changes are much more likely to be written, tested, and put into operation quickly if the codebase is modern."
Response: "Define modern. This sounds very much like the usual rant about having to periodically update legacy S/W i.e. the stuff that's earning the business's income."
Modern refers to the original comment about businesses continuing to run code written in the 1980s because, as the comment claimed, that software was just written really well then so they have no problems. Not only do I not believe the software was just wonderful then, as it probably had plenty of bugs that had to be removed from it back then, but it is difficult to change. Code written in the 1980s will still run, but only on legacy hardware or operating systems which imposes another cost on the business. If you need to update how the software works, your options are:
1. The codebase was written in the 1980s in a 1980s language. In order to modify it, you need people familiar with that language. This is not a ton of people. Many of the people who are familiar with it, looking for a job, and willing to work for you have been writing in different things. I know, for example, a person who wrote assembly for various Cray supercomputers. I don't think he would know how to do that now, though he'd be faster to relearn it than would I.
2. The code is written in a modern language. This may be painful to port from the original code, but it is now easier for it to be modified. You still have to hire good programmers, and you shouldn't do it as cheaply as possible because you'll end up with terrible bugs. However, when you need something updated, it's much easier to find a competent person if the language is more modern. If I found a bug that needed to be fixed quickly, I'd much rather the code be written in C, Python, Java, or most other modern languages than Cobol, because I know I can find someone to write in those languages. I don't know how to find a competent Cobol person, let alone assembly for $random_processor_from_three_decades_ago.
Therefore, I would disagree with the assertion that companies should continue running old code because people just don't write how they used to. I think that's a dangerous course of action most of the time, and although many modern companies forget important testing practices and the like, there are others that still produce reliable code.