All of your proposals have serious flaws. * Bugs caught in test - testers file more bugs given the same number of defects. * Lines of code (less is better) -

All of your proposals have serious flaws. * Bugs caught in test - testers file more bugs given the same number of defects. * Lines of code (less is better) - People talk more, do less. * Hours of maintenance required after release - Developers delay release excessively for testing. * Bugs found after release - Developers look less hard for bugs. * Downtime caused - Developers avoid working on things that might cause downtime. * Time delayed due to developer - Impossible to measure. * Ready before deadline - Developers test less rigorously, cut features. * Speed of the application - Application will do less, or developers optimize beyond what is necessary. * Longevity of code - Not strongly connected to quality, dependent more on organizational use case. My point is not to get you to come up with new proposals, because they will likely fail too. It's to get you to realize that the entire idea of coming up with these metrics, or balance them, does not make sense. You would not say to a water colorist that you would compensate him based on how little red paint he wastes or how many square inches he paints.