> I am not arguing that all software should be held to the > same standard wrt any given metric. For example, I expect > that medical applications to be more thoroughly tested > than, say, a video game.
Actually, in practice, it would surprise me if this were generally true. At least console video games get very hard testing for their domain; the general rule for allowing a release used to be 100 hours of testing without finding any flaw, *after* all flaws found in previous testing had been fixed. I suspect that medical software that isn't used in life-and-death situations see significantly less quality assurance.
This illustrates a point: It is very hard to accurately define what domains it would be reasonable to use what metrics over. "Medical software" isn't a single domain - there's a large difference between a reporting app in psychiatry, where a crash is just an annoyance wasting a bit of a doctor's time, and the embedded software running on a pacemaker, where a crash kill the user.
It is even different in different parts of the same app. In the reporting app, recording data may be critical - it's non-fixable - so that part of the code may need be simple, well tested, well documented, etc. On the other hand, a graphical version of textual report generated by the tool may be called up once a forthnight and save a user 10 minutes. Here, the code is non-critical - it can be complex and not have automatic tests. This may be OK, in the same way that lack of automatic tests for video games is OK, because the code end up with very little maintenance done, and manual inspection of the output as OK and manual testing finding that the code run without crashes/memory leaks can be enough.
So, I don't think we need standard metrics. What I think we would probably benefit from is good metric tools and practitioners with knowledge of metrics, so the developers themselves can use metrics to find out what to clean up - possibly most when picking up a new codebase.