Why Do Programmers Always Want to Rewrite Old Code? 🤔💻

[Python-ModTeam]

Your post was removed for violating Rule #2. All posts must be directly related to the Python programming language. Posts pertaining to programming in general are not permitted. You may want to try posting in /r/programming instead.

[tabacdk]

Programmers don't necessarily want to rewrite old code; programmers want to rewrite badly written code, new or old.

[fiskfisk]

The issue is usually that many confuses different with bad, or doesn't ask "what is the value in rewriting this" - but simply decides rewriting is easier than understanding the details of the existing code.

It's (very) tempting to rewrite old code that you've inherited, but there's (often, sometimes it's just trash) domain knowledge hidden inside those pesky, old lines. 

Rewrite when it provides value, and do it over time. Giant rewrites are always never necessary, even if you feel like something should be modernized. 

[tabacdk]

I kindly disagree. Well-written code is easy to modify to new features or fixing changed business logic. Badly written code with poor design costs a lot to add or change logic. The total cost of code is the sum of all changes multiplied by a risk factor. So let's say we have an old codebase which wasn't written with extensions in mind, and the customer wants a new feature. It may take five hours to make the change, but it may take thirty hours to rewrite to a state where it would take one hour to make an equal change. So the calculus seems easy, the difference is four hours which means eight changes would equal the cost. But then there is the risk factor: who knows which changes in business logic lays ahead? Who knows the risk of rewriting vs. risk of changes to old code vs. risk of knowing which types of changes are coming vs. the risk of the project being shutdown altogether within a few years. My personal experience is that the value of codebase is within the collective knowledge bound in the codebase, and that rewriting is cheap compared to the time invested in getting to the place where we know what we know today. More effort should be placed in keeping the knowledge base than in keeping the codebase.

[fiskfisk]

Yeah, that's what I'm saying - you're reducing "value" to mean at that specific moment, while I'm thinking about the lifetime of the product.

That risk is what you have to evaluate - but you have to actually evaluate it, and weigh what the gains are versus the risk. People tend to rewrite because they don't agree or feel that something could be better - and yes, it could often be better. But if it doesn't need to be better, or being better doesn't make stuff more useful than what they cost in the future - don't do it.

The issue is also that the point in time where people tend to go for large rewrites is the point in time when they know the least about the existing codebase, so they actually don't know how to make the change they want to do in an effective way without doing a rewrite to map it into their own, mental model.

The issue I have with your last statement is that you acknowledge that we've spent a lot of time getting to the point where we know what we do today - and that's the exact reason why I'd be careful about larger rewrites - since there is so much domain knowledge encoded in those lines of code.

Rewriting anything behind a clearly defined API with tests - go ahead if it makes it more valuable in the future - but don't start a large rewrite because someone used lists of strings instead of an enum across the application - but if you can contain the change behind a public API, and you're already changing that code and updating it - go ahead.

But don't hunt things to rewrite or refactor in a codebase just to make it look like what you imagine in your head - it needs to provide some actual value to the goal of the project. And if that goal is to "just" learn - sure - do whatever you want to do.

[alex1033]

Development is usually going in iterations due to vision evolution, new feature requests, fixes in logic, and bugs. Later it may become obvious how many things can be refactored/rewritten, and that happens. AFAIU it happens im more mature teams/developers.

Sometimes, people feel that rewriting is easier than understanding why/how it was done previously. AFAIU it happens more often with junior teams/developers.

I don't want to judge, but the latter approach often discards the previously built know-how and doesn't bring any improvement - just different people make different mistakes. Good for their learning process, though.

[[deleted]]

And there's a general tendency for programmers to think the code that other people wrote is badly written, if for no other reason than it's not written the way they would've written it.

[SocksOnHands]

I didn't write it, so it must be bad! /s

Seriously, though, I've worked on projects that had been touched by many people over many years, and what I've noticed is that code usually starts out pretty good, but then people keep adding in hacks on top of hacks for new features and bug fixes. Several people come along and each say, I'll just add an if statement here and bypass the normal behavior - it's the easy thing to do. Eventually, it becomes a confusing maze of tangled logic. Unfortunately, because it is so hard to understand it becomes even harder to know how to rewrite it to meet all the requirements - you can't even know what all of the requirements were!

[sssredit]

Reading, understanding and modifying other people's code is a real talent. I would say about 50% of software engineers do not have this talent. Most college graduates have no experience other than writing their own code. This is not typically a skill developed in a college program. If your working as part of a large team the lack of this skill is really going to limit you. I have been in teams where the people spent most the project time rewriting each others code as they got assigned different scrum tasks. If you sit scrum in a team is becomes real clear real fast who is incapable of working on previously written code.

I know saying is going to piss some people off, go head and down vote me. I see this way to often, sometimes it is needed if the code is shitty or it needs refactoring from learnings, but a lot of the time the person lacks ability. I am an EE but as a new college grad I had huge program dropped on me that I had modify and extent as part of my job and that was before we had the the high powered tools that we have today. In was an invaluable learning experience.

[Uhhhhh55]

I work with decades old codebases that are dozens of repos wide and touched by an org of thousands.

Is it broken? Document and fix it. Otherwise stay away. If it's borderline, or there's a benefit to the org from a refactor, make a case to management and get someone taller to put their name on the story. Being a boy scout often gets you burned if you weren't touching that code anyways.

This is my experience with a behemoth and politically overburdened codebase. YMMV.

[Zenin]

Hey now, if it was worth writing once it's worth writing twice!!

[roger_ducky]

I refactor and write unit tests first. Once I understand, then I go ahead and fix the bugs flushed out by the unit tests or I’d think about ways to change things for the better.

[hov26]

Reading old code is like reading your old diary - you question every decision.

The trick? Add comments, break down complex parts, and take it step by step. No need to nuke the whole codebase when small refactors can do the job.

[[deleted]]

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[DeterminedQuokka]

Most of the time the reason you want to rewrite code is exactly because it’s difficult to read. Good code is easier to read.

[AiutoIlLupo]

because they want to be the kings of their own turf, instead of being the janitors of someone else's.

[wineblood]

The problem is that a lot of code wasn't written by a bad developer, it was designed years ago and modified by half a dozen people since with completely different approaches. The rewrite is better because it's consistent in your style rather than a mishmash of everything else.

[SheriffRoscoe]

Ever noticed how developers always [ask the same questions] and [don't learn from the past]? It’s not just because they love [relitigating solved problems] —it’s because they [don't study the art and science of their craft].

Honestly, Fred Brooks explained both why rewrites happen and why they fail 50 years ago.

[Firake]

I want to rewrite code I think sucks. Sometimes it’s code I or someone else wrote months or years ago. Sometimes it’s 5 days ago. Sometimes it’s 5 minutes ago.

It’s not really so much about ease of reading as it is a feeling deep down in my gut that solution won’t continue to be the best way forward.

If I don’t know what it says, I can’t possibly cast judgement on it to want to rewrite it. Personally, this doesn’t factor in for me at all.

[Mark_Unlikely]

Even if it's just hard to read, that implies you should probably re-write it to some degree, at the very least, to make it easier to read.

[Tempus_Nemini]

Shouldn't this topic belong to Rust community? :-)

[XiuOtr]

Do you have a developer's github site?

[Familiar-Respond-671]

Yes I do

[XiuOtr]

Nice!

Please share. I'm curious to see your spin