I'm a C/C++ developer focused on embedded firmware, and my boss has set a rather strict standard: he wants no more than 3 bugs per new feature once we hand it off to the testing team. This feels unrealistic to me, especially since features vary in complexity. I'm looking for credible sources or studies to present to him that might help set a more reasonable expectation for our bug rates. Any ideas?
6 Answers
Strict metrics like bugs per feature often lead to unintended consequences. Developers might become hesitant to tackle complex tasks, focusing instead on simpler features to avoid performance scrutiny. A better approach could be measuring function points, where the standard is generally five bugs per function point, with high performers averaging 2.5.
That expectation seems a bit off. Features can be vastly different in size and complexity, so having a fixed bug count per feature could unfairly penalize those handling the most challenging tasks. Maybe show him some studies that explain this variability in software development.
Banning undefined behavior and magic numbers could go a long way in C/C++. A more sensible metric would definitely consider feature complexity instead of merely counting bugs, which might be a hard sell unless backed by solid data.
According to "Code Complete," the industry average is about 1-25 bugs per 1000 lines of code. Microsoft reported around 10-20 defects during testing, while released products had about 0.5 defects. Given the evolution of coding practices, I'd argue that these figures could serve as a solid basis for restructuring your boss's expectations.
That's a helpful context to provide!
Your boss might not fully understand how complexity affects bugs. Just focusing on the number might lead to a skewed view. It could be useful to discuss the types of bugs and their severities rather than just counting them. Established norms usually highlight that serious P1 bugs should be eliminated before release, not trivial P4s.
Yeah, defining bug priority could really help clarify the quality expectations.
In the end, metrics can become goals. If your team feels pressured to keep bugs low, it could hurt your speed of delivery. Maybe have a chat with your boss about the balance between quality and delivery timelines to keep the team motivated and productive.
I agree, but you might need solid references since he may not take your word for it.