A lot of software solutions we use are unmanageable and it's an elephant that people aren't willing to acknowledge till it becomes a hydra (and it will become one soon enough 😪). A lot of netizens appreciate frequent updates and patches but it comes at a cost. In software development, there are a ton of failsafe to ensure that software solutions are manageable and scalable, some of these failsafe include hiring a team of developers (where less would save you money), hiring other complementary professionals, and documentation).
A RELATABLE EXPLANATION
Complimentary IT professionals like DevOps engineers, scrum masters, and other professionals that ensure separation of responsibility ensure that more eyes peer at code and will ensure best practices. The average netizen doesn't fully understand how hard it is to read code. Imagine for a second that you're asked to give a review of some really important book, only that the book is written in Latin 😂. That's how hard it is to work with unmanageable code.
EXISTENT CONTINGENCIES
Other safety features include involving junior developers in a project. Yes, they're inexperienced, but it's a good thing because you can enforce some things through them, a senior developer writes code using algorithms and methods that make extending harder. I'm not saying senior developers aren't good at their jobs, the problem is they're too good as such you'll need a senior developer to manage or extend code written by a senior developer. If there's no documentation, you may have to rebuild the product from scratch.
If you include junior developers, development is slower, but the code is more manageable in the long run because the code is a lot simpler (albeit at the cost of efficiency) to understand than expert level code. There are several factors that are considered in building a team. One of the domino effects in maintaining enterprise codebases is that bad practices get carried on forward, if there's no documentation in a codebase, the people who extend the codebase will most likely not add documentation to their part of the code.
THE DOMINO EFFECT OF BAD PRACTICES
If there are poorly named variables or methods, extending the code will involve using those poorly named or implemented constructs because code is sedimentary in the sense that in existing projects you have to build on what you met. Another convention that is a double-edged sword is the fact that code writing should be consistent, you shouldn't be able to tell that multiple people worked on a project because their style and flow should be consistent (it makes it easier to read and manage the code).
This can be very disastrous if the code has a bad start, the developers who carry on the project will have to decide on whether to ruin the flow (and improve the code going forward) or continue down the path to writing an unmanageable application. If you've read a book written by several authors who had different writing styles you can admit it's a bit of a hassle to keep up with the flow of the book.
FINALLY
Developers will come and go as such it's a pipedream to believe that a developer (or team) will manage the application indefinitely. This is why some great products fail over time. In the event that there's no documentation and poor coding practices are built upon, there will come a time when it becomes harder to extend the product and it might have to be rebuilt.
Bad practices in code are quite common in the sense that a lot of patches are like a band-aid on a bullet wound, it's a lot like technical debt, only in this case, people knew better and didn't do better because they had other priorities and it wasn't a business need to do better.