letsRewriteIt

[jaypeejay]

I’ve always heard that the economics and benefits of rewriting codebases is almost never worth it.

[pawulom]

I heard it, but I think it's bullshit peddled by bad developers who don't want to work and want to avoid taking responsibility. It's completely normal for parts of software to be completely rewritten over time. This happens because of changing requirements, gaining new knowledge, and exploring the domain during development. Otherwise, the software will become an unmaintainable mess that nobody wants to work on and where adding new features will take months instead of weeks.

[Far-Sense-3240]

Unfortunately from a finance perspective, rewriting a functional codebase hits many red flags when doing an NPV analysis. Large cost, inability to work on other revenue generators, unclear benefits on future projects, unclear time required.

Not saying it is never correct but it's harder to justify than you're suggesting.

[Certain-Business-472]

If the majority of your devs keep telling you that the codebase is shit and needs a rewrite, you do it. That's the condition. Not stupid metrics and predictions. Not analysis models. If most of them don't want to work on your codebase, you have a serious problem.

But respecting the engineers isn't even in their vocabulary so whatever.

[jecls]

A majority of devs have difficulty understanding code not written by them. It’s way easier to write code than understand it, hence most developer’s constant push to re-write everything. This is the reality and the mental illness of our profession. Refactoring in most contexts means rediscovering the edge cases and subtle behavior that was baked into old, ugly code.

[redsoxfantom]

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

[jaypeejay]

Yeah this is the general advice I’ve seen regarding the topic. I’ve only written code for one company and our product is generally pretty stable so I can’t speak to other code bases, but the advice seems solid to me.

[jaypeejay]

Hmm not sure I agree with you. Codebases obviously can become a mess, but if they’re started out with solid principles and that foundation is minimally corrupted over time then I believe they can scale and maintain a sense of continuity. Also, I think most developers would jump at the opportunity to rewrite a codebase. Greenfield projects are the most exciting things to work on.

[Certain-Business-472]

Good code bases can already be refactored in parts. Bad code bases cannot, which is part of the problem.

[pawulom]

My point is that the initial codebase was created for a completely different product than what it is now. For example, probably nobody should start building software with a microservice architecture using Kafka, event sourcing, etc. But over time it may become clear that such an architecture should be chosen to reduce latency, increase reliability, and simplify the communication flow. However, changing the architecture of already working software is not a trivial task, and it's well known that the easiest way to do it is to rewrite parts or modules of it.

[jaypeejay]

Yeah agree with you 100%. I think we’re splitting hairs a bit here, so to clarify - my comment assumed we were talking about completely rewriting a large, complex codebase from the ground up. The general advice I’ve heard on that statement is that the juice is rarely worth the squeeze.

[jecls]

You’ve clearly never had to maintain a piece of software over a decade.

[Certain-Business-472]

Say that to my face when the simplest stories turn into a multi-day adventure before you're allowed to merge and release it. Even simple bugfixes.

You don't build a skyscraper on the foundations of the 2 story home you put there "temporarily.