We could probably go on for some time, and I am sure you have lots you could teach me. When I made snide remarks in my comments, they weren't addressed at you nor did I intend for you to read them that way. They were addressed to an "other" person that I thought both you and I would be familiar with. I am also writing my response to address not just you but other people who don't work in software. I know that you are probably very familiar with all of the things I am talking about.
Anyhow, to your comments and others, cross browser support is trivial these days if you have good frameworks. Angular ships with a whole library of shimms, more of which you can add to your project for legacy browsers like IE 8 and later, and for the most part you don't have to write code specifically for any browser because the framework takes care of it for you. That is the way it should be. Every new project started today should use these frameworks, and the future is a brighter and more optimistic place because of it (except where it isn't, but never mind about that).
The situation my company is in is not all unique, and that was kind of my point. Every company that develops enterprise apps has legacy frameworks, from a by gone era of software development with outdated philosophies and coding standards, and real world business implications that get in the way of doing what is right for the legacy code.
What a lot of people don't understand, including junior developers and outsiders, is how much institutional knowledge is wrapped up in that legacy code. You can't just replace it with better coding standards, because software is more than if blocks and exception handling. It takes a lot of time and money to rewrite apps better. Even a small app can take a medium size team, plus business resources, more than a year. So many expensive problems and challenges that have to be addressed. It isn't a home make over show where you can blow in for two weeks and turn the whole company around. It takes years to get in the spot you are in (largely because you didn't know better or had no other choice) and it takes time to undo it too. The whole time, you are questioning the benefits and the cost, I might add.
There are better systems out there that manage technical debt better, but there will always be technical dept. And coding practices, including test ability and documentation, always has to be balanced and managed with maintainability and short and medium term goals. Tests have to be rewritten when features are redesigned. That takes time. A lot of time. Documentation has to be updated to stay relevant and useful. That takes time too. None of that makes you any money.
If you follow all the best coding practices outlined on the internet, you succeed in turning a productive developer who could produce 3,000 lines of production code every three months, to a frustrated developer who can produce 400 lines of production code, 300 lines of unit tests, and pages and pages of documentation in the same time. Too many developers like to imagine how software development should be, and it just isn't like that. Writing software isn't about developing the perfect, most elegant solution and then leaving it in a vacuum for all of eternity, only to return from time to time to admire the brilliance of your work and the majesty of your algorithms.
If software is like a car, you start out building a go kart, because your customers tells you all they need is a go kart, and you only have money to build a lawn mower anyway, so your are already making the best of it. Later on, they tell you they need a radio, and sometimes people who are apparently very important have to go up steep hills or driver over other cars like a monster truck, so you add on 14 inch tires and a ham radio. Next quarter they want a side car and an upgrade to satellite radio so you piece that together with some spare parts in your garage and some duct tape, and on and on it goes. Software is at best a good core design with a bunch of crap super glued to the top of it. I joke with my coworkers that I should make my code less scale able, because the business team will keep adding junk onto it until it barely stands anyway. It always sucks. Good developers and good project managers manage the chaos, and more importantly, do it all while still providing value to your customers which helps you get paid.