That seems a very formal and ultimately futile way of viewing things.

Right now, your rate is X. Whatever ratio others tell you is good, that will not change your current reality.

And if you say Y is a good rate, then people will stop at Y. Why stop there? Why stop improving after an arbitrary number?

Instead, why don't you measure the current rate and then go into an open discussion with all participants, how to improve your whole process so that this rate goes down.

"Bug rate" is very rarely just a result of developers making mistakes. In my last 20 years, I would say about 10% of what I was presented with as bugs were actually my programming mistakes. The rest were insufficient requirements, changing requirements camoflaged as "bugs" to shift blame and resposibility, insufficient testing despite me asking for more (either more time or more automation) and arbitrary deadlines pushed through, were "done with bugs" is better than "not done yet" for some upper management guy on paper, regardless of the fact that the "bugs" are actually missing functionality not implemented yet, not mistakes a programmer made on existing functionality.

So if you want to improve that, you need to improve the process. All of it. As a KPI of software development it's great. As a KPI for software developers is completely pointless, because it's not in their sole domain to change this.

Measure it. Then improve it. It does not really matter what others achieve there, because what you consider a "bug" is not a globally valid constant. It is important, that your team improves. Whether it improves from 20% to 10% or from 40% to 20% is just meaningless numbers. It measurably improves. That is the important part.

That seems a very formal and ultimately futile way of viewing things.

Right now, your rate is X. Whatever ratio others tell you is good, that will not change your current reality.

And if you say Y is a good rate, then people will stop at Y. Why stop there? Why stop improving after an arbitrary number?

Instead, why don't you measure the current rate and then go into an open discussion with all participants, how to improve your whole process so that this rate goes down.

"Bug rate" is very rarely just a result of developers making mistakes. In my last 20 years, I would say about 10% of what I was presented with as bugs were actually my programming mistakes. The rest were insufficient requirements, changing requirements camouflaged as "bugs" to shift blame and responsibility, insufficient testing despite me asking for more (either more time or more automation) and arbitrary deadlines pushed through, where "done with bugs" is better than "not done yet" for some upper management guy on paper - regardless of the fact that the "bugs" are actually missing functionality, rather than mistakes a programmer made on existing functionality.

So if you want to improve that, you need to improve the process. All of it. As a KPI of software development it's great. As a KPI for software developers is completely pointless, because it's not in their sole domain to change this.

Measure it. Then improve it. It does not really matter what others achieve there, because what you consider a "bug" is not a globally valid constant. It is important, that your team improves. Whether it improves from 20% to 10% or from 40% to 20% is just meaningless numbers. It measurably improves. That is the important part.