just wanted to put this discussion out there again to help me (and potentially others) to get a more professional judgement of crufty software projects.
I think "This codebase is bad, I could do it better from scratch" is a thought most of us had sometimes in our professional carreer, ironically more often as a young inexperienced programmer than later in your career. I guess that comes with a better understanding of the vast complexity of a software project, the respect for value-producing software in production and a less ignorant assessment of your own abilities. Now I am much more reserved to propose a rewrite. However I recently adopted a codebase (and a team) that made me think: When is a legitimate point reached where a rewrite would be actually justified? I worked with it 3 months now and realize:
* There is a substantial amount of Hotfixes from apparently inexperienced programmers (mutable global state, arbitrary waiting statements to battle race conditions) * There is some business requirements that became obsolete (abandoned views, commented out code with no explanation) * A whole bunch of skipped test suites * Two outdated libraries, each of which would demand a very substantial refactoring (vue2 with class decorators -> vue3, dropping of vuex as global application storage) * Generally a missing pattern on how to organize API access, it's pretty much all over the place
What I'd like to hear of the experienced people in this community: Did any of you faced a similar situation with a bad codebase? Which steps path did you go? Rewrite or itearative refactor? How did it go? In retrospect, was it a sane decision? Have you been able to identify markers, or a threshold were rewriting were actually the better decision?
Happy new year to everyone and thanks ahead!
