There are still some other metrics and heuristics you can use, such as number (and coverage) of tests, overall code metrics, number of compiler warnings, that t

There are still some other metrics and heuristics you can use, such as number (and coverage) of tests, overall code metrics, number of compiler warnings, that tell you a little bit about the care put in maintaining the codebase. You can still have quality codebases without those (do I know...) but then you'd have to look at critical business metrics (uptime, latency, satisfaction surveys) or the number of tickets (even there, beware) or the overall 'cost and duration to deliver a fix or a new feature'. As for architecture, it's harder to find generic metrics and guidelines for 'quality'... I won't dive in there but external evaluation by people with no or little idea of the actual domain is not very interesting. Moreover people tend to be biased by either 'we at x have done it like this, and we're successful, so...' and 'we at x have built shit' and it's very hard to get in a sort of clean-slate mindset.