For a number of years, I had a management consulting practice oriented mainly around running static analysis on codebase to build a relational model of it, and then helping management make decisions around it (often retire/evolve/abandon/rewrite type things). During this time, I assessed a lot of codebases and also robo-analyzed something like 1K of them for seed data to place clients in percentiles on concerns like coupling, cohesion, dependency management, etc.
FWIW, I'd generalize some observations:
The main determining factor for our (developers as a whole) collective assessment of the code seems to be, subconsciously, "did I write it" (good) vs "did a teammate write it" (depends what I think of the teammate) vs "did an unknown, departed party write it" (bad). Sort of tongue in cheek in the oversimplification, but largely true.
Most codebases were worse than leadership thought in terms of cost of change, better than developers thought in terms of maintainability.
Just about every codebase has something in it that transcends bad and gets into "astonishing" territory, but that rarely defines the whole codebase.
Rewriting a codebase is almost always a bad idea without substantial change in the team structure.
YMMV.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For a number of years, I had a management consulting practice oriented mainly around running static analysis on codebase to build a relational model of it, and then helping management make decisions around it (often retire/evolve/abandon/rewrite type things). During this time, I assessed a lot of codebases and also robo-analyzed something like 1K of them for seed data to place clients in percentiles on concerns like coupling, cohesion, dependency management, etc.
FWIW, I'd generalize some observations:
YMMV.