In my experience it takes months of looking at existing code before you see the good architecture under the superficial mess.
In other words, work in the current code for at least a year before proposing a re-write.
Source code older the the application doesn't mean much as a statement - any good process will build off a CI system which only takes old source code. The question is how different is the application the code generates from what exists, and what to do about differences.
Massive methods are sometimes a sign that the good architecture missed something. Refactor them of course, but that doesn't mean the architecture is bad, just that it needs to change to fit current requirements.
Documents/comments lie. Their value needs to be contrasted to the risk that they mislead you. I'm not saying you shouldn't have them, just not a much as you think.
The problem with books and research is knowing when to apply them. The rules exist for good reason, but they are really guidelines not rules and sometimes they need to be broken. I'm considering that now in my application, the GUI depends on the business logic depends on the network at first glance, but looking closer I'm debating calling it fine because there is no business logic (network sends 5, business logic changes the type from int to mm/s, GUI displays 5 mm/s), so the complexity of making the business logic the thing everything depends on doesn't seem worth it. Maybe, I'm still trying to figure out where we go next, different guesses result in different optimal architectures: if we were really sure they wouldn't be guesses.
I do agree that you shouldn't do anything without creating a test. Note that test is singular, don't try to create exhaustive tests, not only will it take too long, but you often will waste time on a test that is incidental to the implementation and not required. Create a test or two around something you want to change, and then make your change. You get some assurance you didn't break anything, if you were wrong and broke something, you at least get another test out of it.
Sometimes it only seems completely obvious until you discover an unexpected constraint that the design decision address well. Sometimes those constraints are no longer a limiting factor and you can safely rethink the design, sometimes they are an elegant way to prevent a specific real problem and you shouldn't.
In other words, work in the current code for at least a year before proposing a re-write.
Source code older the the application doesn't mean much as a statement - any good process will build off a CI system which only takes old source code. The question is how different is the application the code generates from what exists, and what to do about differences.
Massive methods are sometimes a sign that the good architecture missed something. Refactor them of course, but that doesn't mean the architecture is bad, just that it needs to change to fit current requirements.
Documents/comments lie. Their value needs to be contrasted to the risk that they mislead you. I'm not saying you shouldn't have them, just not a much as you think.
The problem with books and research is knowing when to apply them. The rules exist for good reason, but they are really guidelines not rules and sometimes they need to be broken. I'm considering that now in my application, the GUI depends on the business logic depends on the network at first glance, but looking closer I'm debating calling it fine because there is no business logic (network sends 5, business logic changes the type from int to mm/s, GUI displays 5 mm/s), so the complexity of making the business logic the thing everything depends on doesn't seem worth it. Maybe, I'm still trying to figure out where we go next, different guesses result in different optimal architectures: if we were really sure they wouldn't be guesses.
I do agree that you shouldn't do anything without creating a test. Note that test is singular, don't try to create exhaustive tests, not only will it take too long, but you often will waste time on a test that is incidental to the implementation and not required. Create a test or two around something you want to change, and then make your change. You get some assurance you didn't break anything, if you were wrong and broke something, you at least get another test out of it.