Heh - I understand that impulse, but when I thought that, I think I was less rational. Why is it bad? I have seen bad codebases (whether for real or imagined cases) but to unravel something that is bad can be a real big chore. There was one case where I felt and still feel a certain project was overly-engineered, but rewriting it (which I took a little time doing) is a lesson in futility, particularly if there is no real technical or business impulse to partake such a mission.

From experience, those announcing that a codebase is bad sounds more resume-driven than technical. It sounds like they want to make a mark more than making a functional difference. "Bad code" that happens to have a knowledgeable team around it is not that bad, it's just not understood by outsiders immediately. Also, given the rate of turnaround in teams and companies, making large and significant rewrites and changes would probably not tend to be seen through to their fullest conclusions, in that one sees the long term effect of a large rewrite.

I think if a codebase is actually bad and if codebase aesthetics are an important aspect to one's career, finding the next company with a potentially better codebase is probably a better thing to do than blanket and uninformed critiques about other people's work. :)