43

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?

Community
  • 1
Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • 2
    How much time do you spend writing tests vs. writing production code? – Vaughn Cato May 15 '14 at 13:27
  • Well, the graph doesn't change anything. You're producing twice the bugs, but you're still producing them at half the rate. If you're asking how to reduce the number of bugs in the long term, maybe spend some time learning functional programming so you can reduce how often you rely on inheritance, null, and mutation, all of which are problematic. – Doval May 15 '14 at 13:34
  • 27
    Or just slow down so you can get it right. – Brandon May 15 '14 at 13:42
  • @Brandon That's useful in the short term, but ideally you'd find ways to reduce how long it takes to prove something works, rather than spend more time proving it works. – Doval May 15 '14 at 13:50
  • 1
    @doval - If you follow the second link and look at some of the papers referenced, you'd see that the language used has minimal impact on the bug rate of a programmer according to most of the studies done. – Telastyn May 15 '14 at 14:14
  • 2
    @Telastyn I imagine most studies focused on imperative languages, what with the vast majority of projects being written in such languages. I see mention of "Assembly, C, C++, Java", all of which are imperative. Avoiding `null` and mutation eliminates two classes of bugs and makes proofs actually feasable. You can only do that kind of thing *easily* in a functional language. There's no persistent data structures or Maybe/Option type in most imperative languages. – Doval May 15 '14 at 14:23
  • 1
    @doval - it's not really a imperative vs. functional vs. whatever type analysis. The studies have focused on rates of bugs versus size of projects. Certain techniques are more bug prone, yes, but you can take a step back and start looking at meta aspects of frequency of bugs versus size of project. –  May 15 '14 at 14:25
  • @GlenH7 If your point is that frequency of bugs will still scale with the size of the project, then I agree. But I think it's a big leap to say that you're going to find the same number of bugs in C projects and Haskell projects of comparable sizes, which was the point. There's no way to stop bug rate from increasing with project size, but you can lower the scaling factor. – Doval May 15 '14 at 14:28
  • @Doval - yes, I'm focusing on bugs scaling with the size of the project. And my understanding is that's how must of the studies have been structured. I would think that asking about rate of bugs of Language 1 vs Language 2 would require different methodologies. –  May 15 '14 at 14:34
  • @glenh7 - the primary [study](http://ieeexplore.ieee.org/xpl/login.jsp?reload=true&tp=&arnumber=586152&url=http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=586152) sited did compare imperative C to OO C++ to see if that had an impact, but it largely did not. I have a suspicion that the results would carry over to functional code as well, but have no evidence. – Telastyn May 15 '14 at 14:44
  • 1
    @Telastyn One thing I note is that the study was published in 1997. Mainstream understanding of good OOP design in any language have come a long way since then, and C++-specific best practices have evolved even more so. Heck, the earliest reference I can find to RAII is only from 1994. I can easily imagine a lot of inheritance-related anti-patterns in the C++ code of the time that wouldn't have been present in the C code. I think there's a bigger chance of finding a difference these days, what with the Rule of Three, smart pointers, the slicing problem, etc being more understood. – Doval May 15 '14 at 15:16
  • @Doval: The thing is, all these elements of good design end up simplifying the codebase. A simpler codebase is smaller, and so it having fewer bugs is right in line with what those studies suggest. Of course, we then make bigger projects, which have just as many bugs as software used to, they're just doing a hell of a lot more. – Phoshi May 15 '14 at 15:34
  • @Phoshi Not all elements of good design shrink the codebase though. Using an Option type instead of `null` would technically increase the size of the code ever so slightly, because a null pointer exception amounts to a failure to check for null, something an Option type won't allow you to forget; plus, conversions from null to other types are implicit. All else being equal, null-less code would have the same size or slightly more, but 0 null pointer exceptions. Likewise, composition over inheritance requires more glue code in most languages to set up delegation. – Doval May 15 '14 at 16:07
  • Isnt it simple. Instead of being 4-5 times productive at double the rate of bugs, be 2 times productive at the same rate of bugs as your peers. – Krish Srinivasan May 15 '14 at 18:03
  • Your math is off. I could be way more productive while producing the same number of bugs per story point as my peers. – Telastyn May 15 '14 at 18:58
  • 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 May 15 '14 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". – MichelHenrich May 16 '14 at 02:32
  • 9
    The way you fix this is by fixing the metrics. – Robert Harvey May 16 '14 at 04: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. – Robert Harvey May 16 '14 at 04:43
  • 1
    What type of bugs are you produced, e.g. "simple coding errors", "not understanding spec", "not good ui formating", etc. The answer very much depends on the bug type. – Ian May 16 '14 at 12:41
  • 3
    A proverb that you might tell your boss: He who does a lot of work makes many mistakes. He who does less work makes fewer mistakes. He who does no work at all makes no mistakes. And he who makes no mistakes gets promoted. – gnasher729 May 16 '14 at 13:05
  • 1
    @Brandon: Apparently he doesn't even need to "slow down to get it right". Working two hours a day, he gets the same amount of work done as others, with half the number of bugs, which should keep his boss happy. Maybe better to work three hours a day, to get 50% more work done with 25% fewer bugs than others. – gnasher729 May 16 '14 at 13:07
  • 2
    @RobertHarvey In my experience, managers love to know the rate at which tasks will be DONE. And DONE usually means correctly working feature(s). Consistency in saying when a task is done is extremely valuable for them to plan things ahead. Resources, timeline, demos, sales strategy, you name it. So, my reasoning is that if he is already producing code faster than others, and with a lower rate of bugs, then why not reduce the speed a little and focus on fixing the bugs before saying something is done? There are disciplines for that, As long as understanding the requirements is not the problem. – MichelHenrich May 16 '14 at 23:12
  • 1
    Your third paragraph is actually a misinterpretation of the statistics. Bug rates are fairly constant across programming *languages*, but not across *programmers*. And in fact the highest-performing programmers are not only more productive but also produce far fewer bugs. If you're producing 2x as many bugs *per LOC or function point* then it means you're not actually 5-10x as productive, you're simply trading correctness and design quality for speed, and wasting other devs' time on reviewing the bugs that *don't* slip through. As Brandon says, slow down! – Aaronaught May 16 '14 at 23:56
  • 1
    @MichelHenrich: Oh, great: "*as Uncle Bob says*" - bear with me, but I can't stand this "uncle" thing. This, and his strange attitude of knowing the holy grail of SW development. Even the "uncle" can be wrong, no matter how load and how often he's yelling at you what he thinks is right. Don't you have an opinion on your own? Do you really need the backing of an "uncle"? – JensG May 17 '14 at 16:58
  • @JensG I do have opinions of my own, and if you really read my comments you'll see that. I just quoted Robert C. Martin as I could've quoted anyone else. In this case specifically, where "Professional Attitude" is being discussed, I chose to cite someone who has contributed to the subject in our industry, from which the author can find useful material if he is interested. It doesn't mean that I agree with everything he says. Anyway, considering your replies to me and to awsm's answer, I'd suggest you try to avoid ad hominen attacks. – MichelHenrich May 18 '14 at 02:44
  • 3
    I see this theme in the comments and upvotes: proportions are hard. – sea-rob May 18 '14 at 15:22
  • Honestly it's worth saying that if you really have too much trouble on this one, there *are* smarter managers out there who would love to pay you more... – djechlin Oct 03 '14 at 01:49
  • Here's what I was taught: If you do a lot of work, you make a lot of mistakes. If you do less work, you make fewer mistakes. If you do no work, you make no mistakes. If you make no mistakes, you get a raise or you get promoted. – gnasher729 Feb 24 '16 at 09:16
  • At the risk of being snarky, I think what you're looking for is what the 'cool kids' these days are calling "Quiet Quitting": a strategy wherein you do exactly the minimum that's expected of you and nothing more, collect your comp, and enjoy other pursuits in your remaining time. Your situation sounds crummy, but the implied sense of, 'why can't they see how great I am?' feels unproductive. If "Quiet Quitting" doesn't appeal to you, (it doesn't appeal to me) either change yourself, or change your surroundings and processes. – ipmcc Sep 10 '22 at 13:45

13 Answers13

42

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 May 15 '14 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 May 15 '14 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. – Bart van Ingen Schenau May 15 '14 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. – Pete Kirkham May 15 '14 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 May 15 '14 at 23:06
  • 1
    This answer, and the community's support of it, is a great example of the muddled thinking rampant in our industry, that software is terribly written because programmers have such difficulty with logic and clear reasoning. *"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."* That's insane. "Let's first add all the features, and we'll debug afterwards. Then we'll show how fast we code, and how fast we debug, etc. It's much easier fixing bugs when they're all present!" – Huperniketes May 18 '14 at 04:40
  • 1
    @Huperniketes - you're missing the point. The core of this question is about a manager looking at raw numbers of bugs versus the rate of generation. Nothing within the comment you're complaining about encourages poor craftsmanship. It merely reflects that a programmer with higher productivity will more quickly finish a comparable task than someone with lower productivity. –  May 18 '14 at 13:06
  • 1
    No. It's not about a manager looking at raw number of bugs, or any other metric. It's about a manager who wants his employee to perform better, and an employee who thinks he/she is justified in not complying. – Dawood ibn Kareem May 19 '14 at 19:21
  • 1
    @GlenH7- Again, programmers have trouble with clear reasoning. A line of buggy code is several times more expensive than one which is bug-free. Managers grok this. Look at GM's defective ignition fiasco, and grok this. You cannot reasonably spew lines of code thinking testers and maintainers will clean it up afterwards. Just quit spewing out junk from the get-go. – Huperniketes May 21 '14 at 14:00
21

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.

Philip
  • 6,742
  • 27
  • 43
  • 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 May 15 '14 at 19:43
21

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.

Community
  • 1
JvR
  • 1,184
  • 6
  • 16
  • 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. – Neil Slater May 16 '14 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 May 18 '14 at 06:46
  • 1
    @nomen Oh, but I agree: people absolutely should take that into account. But do they? – JvR May 18 '14 at 12:15
20

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.

awsm
  • 241
  • 1
  • 2
  • 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 May 16 '14 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 May 17 '14 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. – Michael Durrant May 19 '14 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. – Dawood ibn Kareem May 20 '14 at 05:33
8

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.

codenheim
  • 2,963
  • 16
  • 18
  • 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 May 15 '14 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 :) – codenheim May 15 '14 at 23:02
  • 4
    In my experience, comments frequently contain bugs. – Dawood ibn Kareem May 15 '14 at 23:10
  • Not the functional, measurable kind... – codenheim May 15 '14 at 23:12
  • 6
    @DavidWallace, in my experience code frequently contains bugs. It doesn't mean you stop writing it. – Charles E. Grant May 15 '14 at 23:28
  • Maybe quality was NOT a key metric? Well, that happens when gamification is done wrong: people will pick the arbitraging opportunities and start to game the system. It's easy to blame the developer, but the one to blame are the people who set up the ranking system. The dev just did some "REO" (Ranking Engine Optimization), which is hardly a crime. You could easily have done it the same way. – JensG May 17 '14 at 17:05
  • I used to comment a LOT. Now I comment very little. This is because I now write much better code (full english words for names, functions, methods, classes, variables, short classes and methods, etc). I now reserve comments for "this is done this seemingly odd way because of ... and thus should not be refactored" and for code that I am still in the process of removing - though I usually remove the commented code before commit and allow the source control system (usually git) to track. – Michael Durrant May 19 '14 at 21:58
4

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.

Huperniketes
  • 2,205
  • 14
  • 17
3

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
Michael Durrant
  • 13,101
  • 5
  • 34
  • 60
1

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
Marten Storm
  • 11
  • 1
0

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.

Tom Au
  • 893
  • 7
  • 17
0

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.

Dawood ibn Kareem
  • 1,852
  • 12
  • 14
  • 6
    [Zero bugs is a largely unattainable goal](http://programmers.stackexchange.com/questions/195571/is-it-possible-to-reach-absolute-zero-bug-state-for-large-scale-software) that often isn't cost effective. – Telastyn May 15 '14 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. – Dawood ibn Kareem May 15 '14 at 22:47
  • 1
    When you figure out how, write a book on it. :D – codenheim May 15 '14 at 23:06
  • Lots of people have written books on how to write better code. – Dawood ibn Kareem May 15 '14 at 23:28
  • 1
    @DavidWallace - eh, at least for my boss, it's been made clear in no uncertain terms that schedule trumps quality every time, but the point is a good one. – Telastyn May 16 '14 at 00:27
  • 1
    @mrjoltcola, read up on the Message Flow Modulator project at UT Austin in the late 1970s/very early 1980s. Zero-defect code *IS* possible, and it is not that hard to do, *IF* you use the right tools and the right people and the right mindset. – John R. Strohm May 16 '14 at 03:10
  • @mrjoltcola, see also the US Space Shuttle avionics. There was exactly one bug in the code when the bird retired. It was a growth provision, for a second robot arm, that was ultimately never done. The review committees looked at it, and determined that (a) it did no harm to anything, and (b) it would cost more than it was worth to "fix" it, because of part (a). – John R. Strohm May 16 '14 at 03:12
  • 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? – Dawood ibn Kareem May 16 '14 at 03:15
  • @JohnR.Strohm - Sure, I agree, and I never said it was impossible, I was actually having a little fun, but the implication is that defect code is pretty rare, and hard to achieve consistently. Of course, by definition, if you can write 1 line of defect free code, you can write a 100, or 1000. I'd be interested in knowing how you propose to _prove_ that non-trivial code is defect free. I think the best we can do is _observe_ that there are no visible defects. – codenheim May 16 '14 at 03:34
  • @mrjoltcola, again, read up on the Message Flow Modulator. They used a language, and a programming system, that was specifically built around formal proof of correctness as well as "testing". Part of the problem is that C is inherently unsafe and unverifiable, C++ is worse, and Microsoft Windows is a veritable morass of bugs and stuff, meaning that any attempt to write bug-free code in that environment is likely to be quite a bit more difficult. – John R. Strohm May 16 '14 at 05:11
  • @JohnR.Strohm - Absolutely. It rings a bell. I think I ran across it a few years ago when researching VM bytecode verification, and didn't realize what it was at the time. Thanks! – codenheim May 16 '14 at 06:33
  • @DavidWallace - software development isn't archery, it's medieval warfare - can you stop this horde of barbarians from storming the castle and slaughtering you? Sure, it'd be awesome if every archer could put one through their eye socket with each shot, but there's a whole lot of lower quality good enough ways to get that done. Perfect is the enemy of good. – Telastyn May 16 '14 at 12:53
  • 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! – Dawood ibn Kareem May 16 '14 at 13:40
  • The point a lot of people here are making is that good is what we get when we aim for perfect. @DavidWallace's analogy is apt -- aim for perfection, settle for good enough. – Geo Ego May 16 '14 at 16:18
  • 1
    @Telastyn, there are some important domains where "good" is just plain NOT GOOD ENOUGH. Review the Therac-25 case for one example. (Note: Therac-25 is not the best case to review. A competent hardware design would have included a MECHANICAL interlock on the beam power level control, so the high-power electron beam mode could not be engaged unless either the X-ray target or a special testing adapter was mounted properly in the beam path.) – John R. Strohm May 16 '14 at 18:00
  • 1
    @DavidWallace - that is the point though. I'm producing **half** the bugs per feature of my peers (whom _are_ good enough). Why is code with half the bugs not good enough when the more bug-ridden code is? – Telastyn May 16 '14 at 19:56
  • 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. – Dawood ibn Kareem May 16 '14 at 20:02
  • 1
    @DavidWallace An argument that bugs are bad is not required here. If anybody else were performing the same work, the boss would have to budget the resources to fix twice as many. A truly bottom line focused boss could tell him to **increase his speed more** until his bug rate was equal to his peers -- the company still saves money on development time and bug fixing time until **at least** that point -- or recognize a really good situation and leave well enough alone. – Justin May 16 '14 at 20:13
0

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.

Bob Bryan
  • 206
  • 1
  • 7
0

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.

Lutz Prechelt
  • 1,483
  • 9
  • 11
-1

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.

zzz777
  • 456
  • 1
  • 5
  • 11
  • 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 May 15 '14 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 May 17 '14 at 00: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 May 18 '14 at 17:12