[kdjkdjk]

I'm old. I've seen this more times than I can count. There's always a whole lot of assumptions that just never quite pan out as expected, do they ?

Rewrites always end up taking way more time and resources than anticipated, and you'll ultimately end up with something that has fewer features and not necessarily considered "better" by your users. Refactors on the other hand can get you some wins faster, but will probably be abandoned half-way through and as such contribute to the increasing unstability of the code base.

But hey, you're a good cookie, at least you're thinking and asking the questions. I'm sure you can rewrite the codebase cleaner, technically, but can you also pull it off organisationally (long term mgmt committment, sufficient budget, resources, time and priority ?). If you say there are hotfixes by inexperienced programmers, obsolete business requirements, skipped testing etc., you need to ask yourself why that is and how it came to be, and whether you can really pull off a rewrite under the conditions that led to the current situation ?

So yeah, I tend to favor refactoring, at least you'll end up with something.

Also, applicable xkcd: https://xkcd.com/927/

[l0rn]

Yeah, basically I share those doubts. Still I'm still considering rewriting might be worth it at this point still. The question why it came to be is probably mismanagement, changing business requirements, a very inconsistent and highly volatile "microservice" backend made across hundreds of developers across the globe. Corporate shenanigans you name them. So the software being in a weird environment is nothing I can change. I just want this piece, the stuff me and my team works with to still be able to produce new stuff and be as much of a pleasure to work with as possible.

Some notes that make me actually favor a rewrite:

* Despite of being a considerable large codebase not a single piece of software made it past the "just for presentation" purpose - no customers or production software involved. (Also parts of it are infact already cancelled by management and therefore obsolete)

* Team morale is very low as practically any task currently means dealing with a ton of cruft

* We actually piled up a refactoring backlog, that grew so big it practically will touch everything. Like obsoleting an outdated store package that contains 70% of the business logic. Migrating to vue3 will pretty much touch every view as our class decorator syntax stuff won't be straightforward to migrate. Then theres not much left.