They then find out that every complex rule had a reason for existing. The rewrite takes time and resources to reimplement. As they go they hit snag after snag and add a specific business rule for that only to find out that they are just recreating the original "too complex and inefficient" codebase with a whole lot of effort and money wasted.
I've rewritten several of such projects, successfully reduced complexity and improved performances just by knowing what I am doing.
This code is a mess, I don't understand what it's doing is very different from I get what it's doing but this code is a mess.
The first should probably be a strong sign you should not start rewriting the code, while the second can be a decent position to consider rewriting it.
Being unable to understand the code in its entirety does not mean that somebody is unable to understand pieces of the code. Refactoring those pieces into easier-to-understand portions can be done, even when the end-to-end flow is still being contemplated.
Right, but the main point still stands I think, that if you don't understand the full code, you run a risk at introducing bugs when refactoring portions of it.
Code that seemingly does nothing might in fact do something due to non-local effects, ie global variables in disguise, and other pitfalls. A "favorite" is using reflection to modify some non-local variable rather than accessing it directly, making it very difficult to find during code searches.
Sometimes these bugs can be glaring, other times they can be more subtle and only be detected once they've inflicted significant damage to customer data.
I used to think that there existed some queries that would benefit just from being rewritten from first principles. And then someone rewrote them incredibly naively. That is no better than the original!
I think "DOGE" is conceptually a good idea, and if it were executed by a competent administration could lead to great outcomes, as was the case with the USDS.