See also Chesterton’s fence. You don’t want to change something until you understand why it’s there in the first place.
https://abovethelaw.com/2014/01/the-fallacy-of-chestertons-f...
https://abovethelaw.com/2014/01/the-fallacy-of-chestertons-f...
The reasoning goes most 'ugliness' comes from bug-fixes that people encountered along the way, and by re-writing that 'two page function' you lose all that accumulated knowledge. In short, the hacks that make us want to rewrite code are there for a reason
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
A rewrite will solve it in the short term - until requirements change again.
However, I would much rather apply the new 'hacks' onto the rewritten 10 line function than figure out the original 200 line behemoth.
But collectively, it's likely that one of those hacks is there to account for some edge case that's not intuitive and will be missed on the rewrite.
This is a real example at one job in the UK on budget day I used to listen the budget speech live in case it had any impact on the system I worked on.
Each record type and field in that record had its own entry in a MIDAS table so you could process say TELEX records differently to Email, Data etc.
As an aside, as I understand it, refactoring was popularised as a response basically to this conundrum - it's a technique for reorganising code without changing its functionality. So you can gradually "rewrite" your two page function without losing the accumulated knowledge.
EDIT: I think it's also important to mention the value in rewrites, specially on your own code. Spend a lot of time thinking how to make your code simpler, easier to follow, cleaner. That will help you write much better code in the future. A lot of people would benefit from this if they tried. Writing code that works is simple, writing good code is very hard. And rewriting code teaches a lot of the second. When you are learning, rewrite a lot. When you think you know what you are doing but someone suggests to rewrite (and you know they are good programmers too), at least listen.
The age old maxim "sell old products to old customers, and new products to new customers" works pretty well here as well.
How to rewrite the product if all your experts are tied up in the old product is a different question entirely.
For example of industry that seems to be in perpetual rewrite is the gaming industry. But they don't rewrite the old games, the develop new products using partly the existing concepts and software modules.
This product based view also tells you something: when in business, you should never do a rewrite out of purely technical aesthetic reasons, but because of concrete measurable business goals.
Rewriting from scratch means rethinking the design, or basic structure, of the code while keeping all its functionality. It's not about getting rid of hacks, it's about lining them up neatly in one place instead of having them all mixed, twisted, nested and threaded through the code everywhere.
Well, at least if you know what you're doing, instead of just randomly deciding on a rewrite because it's more interesting that way or because you can't be bothered to read and understand the original. Then, I agree completely with Joel, it's most of the time a grave mistake which made countless companies and developers fail.
Isn't this exactly the problem? I know "what I'm doing", but don't have the added knowledge of several engineeers through several years, and rewrite it's not necessarily a 1:1 transcription to a new language or structure.
If something is bothering the team daily, than yes, a rewrite might be needed, which is different, and hardly something I would exclusively by myself.
That's reality, sure, but there's no reason not to document it properly. Inadequate documentation seems to be assumed implicitly here.
If a (competent) reader is thinking Why on Earth does this code do that?, it means you've written unmaintainable code with too few comments around the necessary-but-ugly workarounds that you've used.
If you have properly commented everything, the reader won't mistake the necessary complexity of the code for a giant-ball-of-mud.
If you want to fix it, fix it. Find the other people who are fixing it and collaborate.
Advice I should follow myself: If they fight you on that, get out. They like their ball of mud, and they will turn new code into mud too. If you ever succeed, it will take you until it’s time to find a new job just to get things to tolerable. That’s an incredibly foolish investment in being right.
There are more people in the world that can be taught than there are teachers. Don’t waste your efforts on bad pupils. It just reduces our collective intelligence.
Here's why: I saw a comment in some thread about machine learning yesterday that I think is a good analogy in some cases for what you describe. The comment essentially said that a "never re-write" policy leads to "overfitting" the code to the problems of the past and therefore less flexibility in implementing both fixes for issues and new feature development.
Knowing what I know about how some organizations work, I don't think this is necessarily a safe assumption.
If you're very confident that your test suite covers all use cases, then you can just change it and see what breaks.
That's why it's important to start with some testcases of required behavior, and then refactor only code that is supported by tests. Because sometimes the fence is there for a reason, but often it's not.
The difficulty is making sure that you have all the requirements and aren't missing any, and once a system gets big enough, that gets really difficult.
As an programmer I always try to capture these reasons in my commit messages, after a decade of doing this I’ve gotten a lot of thank you notes years after leaving a project, and I’ve even reminded myself details about my own thought process that I had otherwise would have long forgotten.
One thing I’ve learned by having long tenures is that context change over years is much more likely the reason for nonsensical code than developer stupidity.
> The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
The point is that there might be a reason, and before careful consideration we won't understand what that might be.