> Should I just go and basically say that this person did a bad job?
That's not likely to get good results; you'll want to do more prep work to ground "did a bad job" in data. That data will also be useful in making the "rewrite everything" decision, should things come to that.
Start off at the organizational level: how did this code get into production? You're not going to get anywhere arguing for code quality at a place that doesn't value it. Is the rest of the codebase like this? If it is, you may be facing a larger company-culture issue.
Making real improvements is going to be seriously difficult without automated testing, so you'll probably need to add testing incrementally. Maybe start off by reproducing a production bug in a test and then fixing it - this delivers immediate business-visible value faster than stopping the world to write tests. Whenever you make changes, wrap the affected part in some more tests. Are there manual acceptance tests? Consider automating some of them.
Finally, be prepared to bail if nothing works - some places suffer from the "Market for Lemons" problem, where good developers who join figure out it's a dumpster fire and leave behind only bad ones.
That's not likely to get good results; you'll want to do more prep work to ground "did a bad job" in data. That data will also be useful in making the "rewrite everything" decision, should things come to that.
Start off at the organizational level: how did this code get into production? You're not going to get anywhere arguing for code quality at a place that doesn't value it. Is the rest of the codebase like this? If it is, you may be facing a larger company-culture issue.
Making real improvements is going to be seriously difficult without automated testing, so you'll probably need to add testing incrementally. Maybe start off by reproducing a production bug in a test and then fixing it - this delivers immediate business-visible value faster than stopping the world to write tests. Whenever you make changes, wrap the affected part in some more tests. Are there manual acceptance tests? Consider automating some of them.
Finally, be prepared to bail if nothing works - some places suffer from the "Market for Lemons" problem, where good developers who join figure out it's a dumpster fire and leave behind only bad ones.