Many times, I have been shown architectural diagrams that painted pretty pictures of what turned out to be disastrous codebases. In retrospect, there were othe

Many times, I have been shown architectural diagrams that painted pretty pictures of what turned out to be disastrous codebases. In retrospect, there were other, non-technical "smells" that indicated that the sausage might not be so well made -- dumb developers, vague managers, production broken-ness, etc. I've seen a lot of Java codebases over the past decade, ranging from good to awful. To get a feel for the overall quality, I've learned to check out some common things that are usually indicative of overall quality. For example, bad developers never seem to understand exception handling. Database connection management is another easy spot to check out -- letting the pool close up one's connections seems to be a favorite pastime. Other stuff that's not necessarily Java specific -- use of custom frameworks that, according to the developers' own descriptions, are replicas of existing stuff. Perhaps, as @hga pointed out here, sitting at a terminal with an experienced developer and insisting that he/she show you the stuff you want to see (as opposed to a passive, guided tour) would be a quick way to gauge overall quality. And, you'd get a pretty good idea of management's notion of "experienced developer."