So it is generally accepted that top tier programmers can produce an order of magnitude more/better code than their more average peers.

It's also generally accepted that the rate of errors made in code is relatively constant for programmers.

Instead, it tends to be impacted by the processes used when writing the code and after the code is written. (As I understand it) Humans tend to make mistakes at a fairly constant rate - better programmers just notice more of them and are quicker to fix them.

  • Note that both of above assertions come from Code Complete by Steve McConnell - so it's not a matter of differing perspectives.

So I've started to see this recently in my code. I can hammer out about 4-5x the amount of code as many of my peers (measured by story points estimated by the team), with higher quality (based on performance metrics and number of changes made after check-in). But I still make mistakes. Between better unit tests, a better understanding of what the code is doing, and a better eye for issues when doing code reviews I'm not producing 4-5x the number of bugs.

But I'm still producing about twice as many bugs found by QA as other developers on my team. As you might imagine, this causes some problems with non-technical folks doing metric measurements (read: my boss).

I've tried to point out that I'm producing bugs at half the rate of my peers (and fix twice as many), but it's a hard sell when there's graphs saying I produce twice as many bugs.

So, how to deal with the fact that increased productivity will lead to an increased number of bugs?

  • 27
    Or just slow down so you can get it right.
    – Brandon
    Commented May 15, 2014 at 13:42
  • 30
    From a practical point of view, it sounds like you're being paid more for bug avoidance than code generation. So spend 1/4 of your day writing code for your company, and spend the rest of the day writing code for your own side projects. By the criterion he's set up, your boss should love you.
    – sea-rob
    Commented May 15, 2014 at 19:16
  • 15
    I don't quite understand why our community seems to celebrate "speed" more than correctness. And I write "speed" in quotes because if you have to go back to fix things, then maybe its not real "speed". In the end, you are being paid for delivering working software. If by writing code faster than average you are producing bugs, whether by skipping tests or not understanding the requirements correctly, then take some of the time you "spare" and use it for improving your tests/requirement understanding (for instance, are you doing TDD?). As Uncle Bob says, "if you want to go fast, go well". Commented May 16, 2014 at 2:32
  • 9
    The way you fix this is by fixing the metrics. Commented May 16, 2014 at 4:42
  • 25
    @MichelHenrich: If he's producing bugs at half the rate of his peers, then speed is not the problem; management is the problem. You're reading these goofy metrics the same way his bosses are. Commented May 16, 2014 at 4:43

13 Answers 13


I think you're mixing your concerns. And there's nothing on your side that you need to change.

Productivity is a hint at how quickly a project will be completed. Project managers and everybody else like to know when the project will deliver. Higher or faster productivity means we'll see the project deliver sooner.

Rate of bugs isn't tied to productivity but rather to the size of the project. For example, you may have N bugs per Y lines of code. There is nothing within that metric that says (or cares!) how quickly those lines of code are written.

To tie that together, if you have higher productivity, yes, you'll "see" the bugs being written more quickly. But you were going to have that number of bugs anyway since it's tied to the size of the project.

If anything, higher productivity means you'll have more time at the end of the project to hunt those bugs down or the developer will be faster in finding the bugs they created.1

To address the more personal aspects of your question.

If your boss is looking strictly at the number of bugs you produce as opposed to the rate of bugs you produce, an educational session is in order. Number of bugs created is meaningless without a backing rate.

To take that example to the extreme, please tell your boss I want double your salary. Why? I have created absolutely no bugs on your project and I am therefore a much superior programmer than you. What? He's going to have a problem that I haven't produced a single line of code to benefit your project? Ah. Now we have understanding of why rate is important.

It sounds like your team has the metrics to evaluate bugs per story point. If nothing else, it's better than being measured by raw number of bugs created. Your best developers should be creating more bugs because they're writing more code. Have your boss throw out that graph or at least throw another series behind it showing how many story points (or whatever business value you measure) alongside the number of bugs. That graph will tell a more accurate story.

1 This particular comment has attracted far more attention than it was intended to. So let's be a bit pedantic (surprise, I know) and reset our focus on this question.

The root of this question is about a manager looking at the wrong thing(s). They are looking at raw bug totals when they should be looking at generation rate versus number of tasks completed. Let's not obsess over measuring against "lines of code" or story points or complexity or whatever. That's not the question at hand and those worries distract us from the more important question.

As laid out in the links by the OP, you can predict a certain number of bugs in a project purely by the size of the project alone. Yes, you can reduce this number of bugs through different development and testing techniques. Again, that wasn't the point of this question. To understand this question, we need to accept that for a given size project and development methodology, we'll see a given number of bugs once development is "complete."

So let's finally get back to this comment that a few completely misunderstood. If you assign comparably sized tasks to two developers, the developer with a higher rate of productivity will complete their task before the other. The more productive developer will therefore have more time available at the end of the development window. That "extra time" (as compared to the other developer) can be used for other tasks such as working on the defects that will percolate through a standard development process.

We have to take the OP at their word that they are more productive than other developers. Nothing within those claims implies that the OP or other more productive developers are being slipshod in their work. Pointing out that there would be less bugs if they spent more time on the feature or suggesting that debugging isn't part of this development time misses what has been asked. Some developers are faster than others and produce comparable or better quality work. Again, see the links that the OP lays out in their question.

  • 44
    "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." -Bill Gates
    – Neil
    Commented May 15, 2014 at 13:39
  • 40
    Great programmes might actually produce more errors than the average programmer - because great programmes tend to work on harder problems.
    – hlovdal
    Commented May 15, 2014 at 14:00
  • 4
    Bugs/K lines or bugs/storypoint would be a fair rate. I would run as fast as I can if the boss wants to use bugs/hour as a rate. Commented May 15, 2014 at 14:09
  • 4
    "Your best developers should be creating more bugs because they're writing more code." no, they should be either preventing bugs or finishing more features. Often that means they write less code, or even remove swathes of code. ( you probably know that, just didn't quite write it that way ) Certainly in some industries I've worked in, (e.g. aerospace and nuclear ) the only code which counts is the code which is proven to have zero defects. Anything else is noise. Commented May 15, 2014 at 22:08
  • 4
    "If anything, higher productivity means you'll have more time at the end of the project to hunt those bugs down or the developer will be faster in finding the bugs they created." - I think this is spurious and needs more careful anaylsis. Put it this way: if he spent more time on each feature, yeah, he'd have less time to squash bugs. But there would also be less bugs to squash.
    – occulus
    Commented May 15, 2014 at 23:06

Spend some of that extra time cleaning, polishing, and testing your code. There will still be mistakes, but there will be less. That takes time. Your code output rate will go down, but your bug-free code output will increase, and that will result in better productivity. Because bugs are expensive.

Can you keep your code in a branch or a test environment until you kick it around and catch more of the bugs? Bugs in a branch generally cause less waves than bugs in production code.

But I'm not exactly digging your asserts leading into your question. And perhaps your boss isn't either.

I don't think that every coder produces the same rate of errors. Your second link is actually entirely off topic as it's comparing different languages, not different coder skill levels. Code complete mentions some large-sample measurements that are looking at the process rather than the skill of the coders. And when they say that top-tier coders produce more/better code, part of that means that it has less bugs. Depends on the application. So, yeah, I think it IS a matter of differing perspective.

In the end though, if the boss wants cleaner code, give him cleaner code.

  • 4
    +1. I don't know why the other answer has so many upvotes. It sounds like you've already given good reasoning to your boss and he isn't listening. So spend more time testing and less time "releasing" lines of code. If that's not okay, change jobs.
    – durron597
    Commented May 15, 2014 at 19:43

I'll go out on a limb and be the devil's advocate. That's not to say I don't sympathise with your plight but, well, my sympathy won't help you. So allow me to add to Philip's perspective:

Your boss cares about the quality of the product, partly because his or her name and reputation will be tied to it. Part of the quality is the perceived amount of bugs. If you sell an awesome drill that drills four times faster than any competing drills, but also breaks down twice as often, you'll have a bad reputation. Even if it's arguable that the drill performs better, people get used to the speed, but they'll remember the breakdowns.

In hindsight, most bugs are obviously preventable. If only you were a little more careful, your boss will feel, you could avoid these issues and any necessary clean-up. From his perspective, that's a trivial, sensical thing to ask, and any arguing you do about it is both not going to work and is going to make you look bad.

He can't measure your superior productivity. You claim higher productivity based on a verifiable metric, so how do your colleagues feel about it? Do they agree, perhaps grudgingly, that you are a more productive programmer, or are you alone in your opinion? You'll make a stronger point if you have other people to back up your assertions.

That's for perspective. Now, how do you go about 'fixing' this frustrating situation you are in?

Do slow down a bit. Mention explicitly to whoever distributes tasks that you're going to try to lower the bug rate (*), so that they're not surprised by your lower intake. If anything, slowing down will reduce the number of bugs assigned to you out of sheer lack of supply.

(*) There's a difference between, on the one hand, acknowledging that there are bugs to your name and that you'll try to lessen that amount and, on the other hand, admitting that you have too many bugs to your name and should take action.

Don't try to convince your boss, because it won't work. Again, that doesn't mean you have to concede your point; you can present a counterpoint and hold your opinion without dismissing his concerns. Because if you do argue the point and cannot satisfactorily prove your superior productivity (and even if you can), you're going to risk insulting your colleagues, or appearing dismissive of them. You don't want to be that guy.

  • 4
    My favourite answer, and also the closest one to a point I'd like to add: What is the value of a completed number of story points, and what is the cost of a bug to the company? The OP may find with those things weighted by the bosses' priorities that it is in fact more productive to create only twice as much code as other devs, but with much less defects. Commented May 16, 2014 at 23:35
  • 2
    Your point about the drill depends on a lot of things. In particular, its duty cycle. If a drill works 24/7, and works four times as fast, and breaks down twice as often, you should at the VERY LEAST consider the productivity of the drill. Because if it costs anything less than twice as much as a regular drill, and you can put it to use, it is a better value. You know, economics. You tell him to consider the value of his work, compared to the cost of it. His benefit cost ratio is twice as good as his peers'.
    – nomen
    Commented May 18, 2014 at 6:46
  • 1
    @nomen Oh, but I agree: people absolutely should take that into account. But do they?
    – JvR
    Commented May 18, 2014 at 12:15

Assuming you would produce the same "amount" of code like your colleagues in 20% of their time, you could spend 4 times as much on really debugging the code and making it perfect, which would reduce your bug rate even more. Then you could call yourself a good programmer.

The biggest question is why you are coding 5 times as much as the others instead of aiming for quality. Is this something your ego dictates you or does your boss force you?

Also you need to consider costs for fixing a bug. When you find it early it you might still be "inside" the code enough to fix it quickly. If it appears only after another month of development, it could be hard to find or even force you to change big parts of the already programmed code.

You seem to have the skillset to produce code, and you could make it awesome if you put your focus on quality instead of speed. Try it a while, my guess is you will like it.

The next problem then is to get the acknowledgement (speak money) for your better performance. Talk to your boss and ask him how to proceed, it is his company and money after all, and if he wants you to produce less bugs, he should also decide in which way it happens.

  • 11
    OP is delivering 500% of the story points of the other team members with 60% fewer defects per story point, and you want to change the way he works?
    – Justin
    Commented May 16, 2014 at 20:05
  • 6
    "The biggest question is why you are coding 5 times as much as the others instead of aiming for quality [...] put your focus on quality instead of speed" - You made my day, man. Whoever upvoted this: Please do your basic math homeworks. To tell it bluntly: I would immediately hire the OP and refuse to hire you.
    – JensG
    Commented May 17, 2014 at 16:47
  • 1
    The math might be wrong but I think the point is valid. I'd rather hire someone who aims for higher quality to work in my current company. Needs vary though, especially by industry and company size. Commented May 19, 2014 at 21:51
  • 1
    I would rather hire someone who does what his boss asks him to do, instead of complaining about it on the Internet. Sometimes, the boss knows best. Commented May 20, 2014 at 5:33

Developers can be bright, even genius, with an aptitude for understanding and coding solo, without being GOOD developers. A good developer creates a quality piece of work, and makes the whole project better.

I'm not saying this is you, but one of the most frustrating programmers I ever worked with wrote more code than anyone on the team, and we had good people on the team. We tracked commits with a ranking software, so it was almost a competition for some people. He churned out swaths of code, leaving behind him ZERO documentation, impenetrable forests, and actually made some of my own code hard for me to understand (I can do that on my own, thank you very much!). Eventually he almost derailed the project, because he became a one man show. People could not follow him. We were not in synch as a team. We actually rewrote some of his features years later, just to regain maintainability.

The thing I wanted from him was to slow down, and spend more time: 1) Improving the quality of the codebase 2) Communicating with the team 3) Working on things that helped others as well as help him finish features / stories 4) Fixing bugs

I don't agree with measuring productivity by lines of code, but it is a key metric. Does your code counter include comments? If so, there is an easy way to maintain your line output while reducing your "bug ratio"; simply increase the quality and quantity of comments you write. Comments rarely have bugs (though they can) and in general, we don't have enough quality comments. I am not condoning code-inflation, but the act of commenting is like a mini code review, it forces you think, refactor and improve.

  • 1
    A good point. I don't agree on adding comments (since clearer, more readable code is better), and we measure by story point complete not lines of code. I feel as though I do a good job with this (code reviews help people to help me make things clear), but +1 because certainly not everyone does.
    – Telastyn
    Commented May 15, 2014 at 23:00
  • 1
    I don't mean to add fluff / boilerplate comments. I just made an assumption that you are like most of us, and don't comment enough. Yes, stay away from worthless comments, especially fancy ascii art, unless its some good humor :)
    – mrjoltcola
    Commented May 15, 2014 at 23:02
  • 4
    In my experience, comments frequently contain bugs. Commented May 15, 2014 at 23:10
  • Not the functional, measurable kind...
    – mrjoltcola
    Commented May 15, 2014 at 23:12
  • 6
    @DavidWallace, in my experience code frequently contains bugs. It doesn't mean you stop writing it. Commented May 15, 2014 at 23:28

Trying to enlighten management is a non-starter. There's an old cliché, "Are you going to believe me or your lying eyes?" What concerns your bosses are the bug counts. No amount of rationalization will tell them it's acceptable. It's more than twice as risky. In addition, you're not the only one affected by your bug count. QA has twice the work trying to identify your bugs, so management is going to want you to make less of them.

The best solution is to reduce the number of bugs you produce, period. Not only will management be happier, but you will be too. Won't you? Cause I'm pretty sure as much as you enjoy boasting you outperform your coworkers by a factor of four, you'd love to say you do it making the same number of, or even less, bugs than they do.

As you stated, "…the rate of errors made in code…tends to be impacted by the processes used when writing the code and after the code is written." If you want to alter the rate at which you produce bugs you're going to have to change the processes you use to write code.

Programmers use production methods to produce code, much as an assembly line uses methods to produce some mass-produced object. Okay, the software industry's practices are more like whittling knick-knacks from branches found in the woods. But since we're producing machines, we should employ the same rigor and discipline used for the high-speed machines of mass-production.

That includes the same techniques used in mass-production to reduce the defect rate: root-cause analysis to determine why bugs are made, and change the process so they aren't. Or at least that you catch before QA does.

  1. Make up a list of your bugs. You've probably already got one thanks to the QA guys. Possibly categorized too. Type of bug, severity, the point at which the bug was injected into the code, etc.

  2. Pick the largest category of bugs. Since your volume is so high, you should target that category first. Other categories include the ones easiest to find, and the ones easiest to make.

  3. Knowing where those bugs are introduced into the code, look into making changes at that phase (and earlier) that prevents those bugs from happening, and ways to make catching them easier at that phase.

  4. Be sure to look at non-programming related incidentals as well as they may make a difference in the quality of your work. Background music, interruptions, mealtimes, working too long without a break, hunger, etc.

What you find may lead you to go slower. On the other hand, it may help you produce even faster as you'll have less need to rework stuff you've already put behind you. As it is, four times as much code isn't close to being an order of magnitude better than your coworkers, so changing your process is most definitely the way to go.


Change your objective from producing the most code to helping the company move forward the most.

Since it seems you have many colleagues plus extra time available, the most effect you can have on a quicker delivery of features and bug fixes is to help your colleagues.

Help your colleagues by

  • using code reviews to improve code quality and education.
  • creating process automation to make their work faster and their lives easier.
  • writing better tests with them
  • attacking technical code to improving the code base
  • being the go-to guy that is always available to help others.
  • writing / improving tools that help with developer productivity
  • making the case with management for better tools /equipment / working conditions for your co-workers if you have more clout.
  • preparing for and leading educational sessions on writing better code.
  • practising humility

So, how to deal with the fact that increased productivity will lead to an increased number of bugs?

Your boss is the only person who can answer this in your case. Talk to him, point out your better ratio and let him decide. If his decission doesn't make sense, it is time to look for a company with your way of thinking.

As professional you should be able to work with any given client conditions, just make sure they understand the consequences. A nice bug/stories chart can help your boss understand how much your productivity will sink if you take the time to produce less bugs.

You also need to consider these points:

  • complexity of stories, for example simple getter/setter wrappers versus statistical calculations or real time programming or even real time statistical ...
  • severity of bugs, is it small typos on text fields or wrong calculation results, program crashes
  • cost to fix the bugs, both if you do it now, later or if someone else has to understand your code because you left

The situation is that you work four times as fast as the average programmer, but you make twice as many mistakes in a given amount of time. Relative to the amount of work you do, you actually make HALF as many mistakes as "average."

You might try to point out your low mistakes to work ratio, or even mistakes to completed product (which you can complete in one-fourth the normal time). Most bosses will accept that.

There are a few bosses that won't because they work with an "allowance" mindset of mistakes per time. Then you might slow down your work pace, doing TWICE as much work as average within a given time, and make the same (or fewer) mistakes because you have more time to check your work.


If your boss wants you to improve the quality of your work, then improve the quality of your work.

You should be aiming at zero bugs, not aiming to produce only twice as many as the next best programmer.

  • 6
    Zero bugs is a largely unattainable goal that often isn't cost effective.
    – Telastyn
    Commented May 15, 2014 at 22:44
  • 7
    That is not an excuse for not reducing your error rate. If your boss wants you to produce better code, then it's time to produce better code, not to make excuses about it. Commented May 15, 2014 at 22:47
  • 4
    I only said you should aim at zero bugs, not that you must achieve it. Think of archery. I am no good at archery - I have never hit the "10" in the centre of the target. Should I aim at the "7" ring, because "10" would be too difficult? Commented May 16, 2014 at 3:15
  • 6
    Yes, but your boss is saying that your work is NOT "good enough". In other words, you should do better. You haven't given one good reason why you can't do better. This whole discussion sounds to me like somebody trying to make excuses for producing bug-ridden code. "I'm in a team of very slow developers, and therefore I have to make twice as many mistakes as everyone else". Please! Commented May 16, 2014 at 13:40
  • 3
    Every release cycle, you are producing twice as many bugs as your peers. Bugs are expensive to find and expensive to fix. So your boss has to budget the resources to get your bugs dealt with; and it's twice as much for your bugs as it is for the next guy's bugs. Therefore, your boss wants you to produce fewer bugs, regardless of what the rest of your team are doing. Maybe he knows that you have more experience than the rest of the team, and therefore should be able to produce fewer bugs. In any case, I don't see why you'd complain about having a boss who wants you to produce fewer bugs. Commented May 16, 2014 at 20:02

You should tell your boss that the metrics he is using is quite flawed. If you take a look at turnovers by guards in the NBA, you will find that they tend to have higher numbers than forwards. But, that is because they are handling the ball more. If a non-starting guard plays 1/5 as much as a starting guard and turns the ball over 3 times on average .vs. a starting guard that turns the ball over 7 times per game - at first glance it might look like the starting guard is worse. But, if you divide the number of turnovers by the number of minutes played, then clearly the starting guard has much better numbers based upon minutes played.

Likewise, you have much better numbers if the number of bugs is divided by the number of story points completed. So, that is what I would propose to your manager. Change the metric to be the number of bugs divided by story points completed, or at least add a new metric for this if the total number of bugs per developer is needed. But, since some story points are much harder and more complex than other story points, there can and will be quite a bit of variance and this needs to be taken into account by the manager as well.

What I don't think you should do is to slow down.


Measure value added

Argue that what really counts is the value you add. Then go and introduce rough (manual) measurement of that:

  • Estimate the value of the functionality you produce
  • Subtract your salary
  • Subtract the estimated cost of your bugs (at least the cost to fix them)
  • Subtract the estimated cost of all other Technical Debt you produce

The remainder is your value added. Likewise for everybody else.

These estimates are hard, but even rough ones may make the point. And the mere process of discussing these estimates is useful for the team and the project.


Top programmers have a tendency to write very regular code that is easy to debug and understand, they utilize available tools (static analysis, compiler errors, debug code) to the max. Also, top programmers already learned the value of unit-testing through there own hard experience.

So while initial amount of problems per line is the same, the problems are weeded out faster.

  • question points out that this doesn't help: "I've tried to point out that I'm producing bugs at half the rate of my peers (and fix twice as many), but it's a hard sell when there's graphs saying I produce twice as many bugs..."
    – gnat
    Commented May 15, 2014 at 16:24
  • This is relative and rather subjective, isn't it? I don't know what "regular" code means. I would argue that top programmers attempt to utilize all the libraries and language constructs available to them to their maximum benefit in terms of productivity and expressiveness, which should make the code very easy to understand by other high-functioning programmers... but could in fact be extremely difficult to understand by junior to intermediate programmers, particularly those who are not familiar with the more advanced architectural concepts, control flow, data structures...
    – Aaronaught
    Commented May 17, 2014 at 0:03
  • IMHO, greatness is defined by the long time track record and 90% of living software engineers never had a chance to meet great ones. I tried to summarize my impressions from two great programmers I happen work with. "Regular" code means: (a) the same things are done the same way across all produced code, (b) it is easy to interpret an modify, and (c) it is definitely opposite to "easy to understand by other high-functioning programmers... ".
    – zzz777
    Commented May 18, 2014 at 17:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.