>> The metric would consider "issues resolved," but only after normalizing for implementation complexity, so developers that work in front-end systems don't tak

>> The metric would consider "issues resolved," but only after normalizing for implementation complexity, so developers that work in front-end systems don't take the lion's share of credit after resolving a myriad of tiny tickets. Only if you are not being rewarded for solving your own bugs. Otherwise, I've seen this go horribly awry. I was at a Big 5 consulting company where one project was big on "how well you managed issues and brought them to resolution". That meant that good developers who prioritized code coverage and mostly bug-free code did not have good issue resolution case studies to cite during promotion cycles. After a year of good developers getting dinged on this, some good developers banded together to purposefully leave known bugs in the release (especially bugs that could be blamed on vague specs -- so instead of trying and resolve issues during dev cycles, they were propagated to production). Then, the developer would swoop in and do lots of "investigation", produce a fancy write-up and email (carefully cc'ing senior management) and throw the business analyst under the bus. Senior Management naturally was impressed and some of the developers got promoted for their "leadership" and management of "critical bugs." Bad Incentives --> Bad Outcomes