They call it the Real World™ for a reason.
99% of what you will encounter in the real corporate world will be considered crap, and for good reason that I will explain. The 1% that isn't considered crap will become crap eventually.
#1 Write Code, #2 ????, #3 Profit!
First off businesses exist to turn a profit, they do not exist to generate mountains of perfectly theoretically clean designed and pristine academic code housed in golden repositories of perfectness. Not even close, not even the ones in the business of selling source code they produce.
In the business world code is a means to an end. If some code solves a business problem and makes more money than it costs to create and maintain then it is desirable for the business. Employing you to write code is just one way for the business to obtain code.
Theory 0 - Practice ∞
Ideally maintenance should be more of a concern but it usually isn't, because in the short term it doesn't win out financially. In the long term, software usually has a relatively short life cycle, especially web based applications, they get obsoleted quickly and re-written more often.
In house line of business applications are the ones that churn on as what are perceived as endless zombie projects because of many momentum based reasons. These projects are actually successes they continue because they continue making the business a profit.
In theory there is no difference between theory and practice. In
practice there is. - Yogi Berra
In theory perfectly architected absolutely clean pristine code bases with 100% code coverages should save companies money, in practice it doesn't even come close to delivering any thing close to a valid return on investment.
Physics of the Software Lifecycle
There is also a super powerful entropy force at work in the world of software. It is a black hole of inevitability that condemns all software to degenerate into a Big Ball of Mud.
The farther you start from a BBM the better, but every software system will eventually get there given enough time. How quickly you approach 100% entropy is determined by where you start and how rapidly you pile on technical debt and how high the interest on it is.
Software systems degenerate and rot because of maintenance, not because of the lack of it. A system that is in place for years with no code changes by definition meets all its requirements and goals and is a success.
It is the systems that require constant change because they started out closer to maximum entropy are the ones that are constantly poked and prodded and it is the maintenance that accelerates the negative change.
Good Enough is Good Enough
Short lifecycle systems like websites that change constantly don't benefit from expensive huge upfront design 100% code coverage in unit tests, because the amortization time is too short to recoupe the costs.
Long lifecycle systems like the above mentioned internal line of business apps, don't really benefit from massive investments of 100% code coverage unit tests either, because the rate of change over the life of the project approaches a constant that is near zero in a non-linear fashion.
That is why end of life plans are more important and replacement systems should be planned just as something is being released, not when it has passed it prime by a few years and unsupportable so a new system must be rushed into place.
They don't teach about BBM as far as I know, I have never encountered a recent CS graduate that knew what it was, much less why it happens.
That is why Good Enough is Good Enough, anything more or less isn't.
There are real estate slum lords for a reason, they make a profit on the run down shanty buildings they own. The make more profit than they spend on incremental maintenance of the run down property. If they didn't they would tear down the building and replace it. But they don't, because the incremental costs are far less than overhauling or replacing the entire building. There are also customers ( tenants ) that are willing to pay for run down property.
No building owner, slum lord or not is going to spend money on a property just because of some academic notion of perfection that doesn't translate to a substantial profit over the associated cost.
No customer is going to pay for upgrades to a software system that is working acceptably to them. No business is going to spend money on just writing and re-writing code for no tangible substantial profit.
Microsoft is most dominate and successful software slumlord there is. Windows did not start getting major foundational re-writes until very recently. And they still haven't dropped all the legacy code from the kernel. It doesn't make business sense to them, people are more than willing to accept the low bar of expectations they have set over the last decade.
This has been a pattern for the 20+ years I have been in software development. It isn't going to change any time soon. This isn't the way people want it to be out of some belief system, it is a reality of external forces on a business. Business drives decision making, profits aren't evil they pay your salary, short term or long term vision is irrelevant, this is a short term industry of constant change by definition. Anyone that argues against good enough to make a profit doesn't understand business.
I spent 15 years consulting and learned very quickly that good enough was just that, anything else was costing me money. Yeah I wanted things to be perfect, but unless you are selling a code base, which 99.99999% of the time you are selling a solution, all that prefect clean organized elegant code is lost and you just wasted your time you will never get reimbursed for.
Progress and Hope
Agile methodologies are a good step in the right direction, at least philosophically. They address the chaos and constant change as a first class citizen and accept it. They reject dogmatic practices, acknowledging that the methodologies and practices should change as well as the requirements and technologies.
They accept the entropy that is introduced by the lack of time or changing requirements, changing staff and the liveness of a software system with the concept of technical debt.
But Agile isn't a panacea, it isn't going to change the fundamental laws of physics and code bases will rot regardless. It is up to management to plan on dealing with the rot before it gets completely out of hand and un-manageable.
Agile when done correctly, helps manage the entropy, slow it down, track it, measure it and deal with it in a planned manner. It won't stop it!
If this is a real philosophical problem for you, you should probably consider other career choices, because the way things work has valid business merit behind it. Open Source projects don't have any better track record, and in many cases the code is even worse than most corporate code I have seen.