Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A manager recently announced that were were spending far too much time fixing bugs. I guess he thinks we should write perfect code all the time (whilst still hitting those impossible deadlines of course!) and it made me wonder what the industry average of time spent bug fixing v writing new code was.

So does anyone have any metrics on time spent bug fixing against new code development? Or is there any empirical analysis of bug fixing time for the industry as a whole? Is 50% spent bug fixing too much, or about right? How about 20% or 33%?

I'm happy to accept anecdotal evidence from personal experience as that would form part of some statistics here that I could compare our performance against.

share|improve this question
9  
your manager sounds very ignorant. Suggested reading for cases like that: Facts and Fallacies of Software Engineering by Robert L. Glass, particularly "Fact 43. Maintenance is a solution, not a problem." Wikipedia article mentions 80% efforts spent on software maintenance –  gnat Feb 10 '12 at 15:02
2  
What is the real problem? Do you have a quality problem? Is your process really inefficient? Or is your manager just wishing that software didn't cost so much? –  kevin cline Feb 10 '12 at 16:47
    
@gnat: your comment is the best answer –  kevin cline Feb 10 '12 at 16:51
    
@kevincline thanks - converted comment to an answer –  gnat Feb 10 '12 at 17:21
    
Maintenance isn't only about fixing bugs (defects) and its amount greatly varies for individual projects (=no definite answer). To me it seems you have rather quality issues. –  MaR Feb 10 '12 at 17:46

4 Answers 4

up vote 11 down vote accepted

A manager recently announced that were were spending far too much time fixing bugs.

Above sounds very ignorant. Suggested reading for cases like that: Facts and Fallacies of Software Engineering by Robert L. Glass, particularly "Fact 43. Maintenance is a solution, not a problem."

Wikipedia article mentions 80% efforts spent on software maintenance.

my manager makes Dilbert's PHB look like a genius :)

Hm given above I'd also take some efforts in analyzing whether all the requests you do are bugs indeed.

In my experience it was way too often that requests for enhancements or new features were submitted as bugs. Good managers involve their programmers in finding out about that - bad managers, well, just keep complaining about too much time fixing bugs.

share|improve this answer
1  
+1: Ordered the book. –  kevin cline Feb 10 '12 at 19:03
1  
Bug fixing != maintenance! Bug fixing means you coded faults in the system and they need to be fixed in order to restore correct functionality. By maintenance I would mean all tasks such as bug fixes, scalability improvements, hardware migration, and performance improvements etc. I would say more than 25-30% of the time being spent just on bug fixes needs a governance call immediately. Up to 40-50% of the effort spent on maintenance overall sounds reasonable for a mid-size enterprise system. –  Monster Truck Jul 29 '13 at 12:29
    
Do you have any figures for the different classes of bug? Obviously if you are getting large numbers of high priority, "show stopper" bugs there may be a case that the development process needs some work to determine the source, but if its all little stuff its not such a big deal. Also as gnat says, many of them may be enhancement requests. –  Stevetech Jul 9 at 20:39

The first question to ask is if your "bug fixing" is actually fixing coding bugs or something else. The fixing of actual code bugs should be relatively small in most cases as long as you have a good code base. If you're working with a poor code base, extensive bug fixing is inevitable.

However, in the course of putting a program into production, you'll find requirements that weren't documented, unexpected user activity, data anomalies, hardware incompatibilities, installation issues and other problems that aren't strictly code bugs. Often managers and users will think of these production support/maintenance problems as bugs since they typically require code changes.

I've also encountered managers who would group what should have been termed as minor enhancement requests as bugs. Often these get entered into a bug tracking or problem reporting system and this can make your "bug" stats higher than they really are.

share|improve this answer
    
What you describe is what we have, but that doesn't change anything :( –  gbjbaanb Feb 10 '12 at 19:53

It depends on how much code you have out there, how long it has been out there, etc.

The time spent fixing bugs in software should be front-loaded to the first 6-12 months of release, however as time approaches infinity, the time spent on maintenance versus the time spent on initial development will exceed 100% - that's just the way things work.

While I don't have any hard statistics (Code Complete does, but I can't tell you exactly which page/section), in my experience roughly 40% of development (sometimes as high as 60%) is spent on maintenance. It's obvious that the more code you release, the more maintenance time you will have. Bugs are not always functional, and are as much a result of uncertainty as they are programmatical defects.

share|improve this answer

if your using a good ticket tracker (Such as Jira from Atlasian) and you've spent time entering all the different categories, user stories, urgency levels correctly and with the agreement of your team mates, then actually calculating these metrics (and more) are amazingly easy.

On a previous project, we used Jira to manage our bug/task/todo lists, and in the end it actually showed us that the biggest cause of delays and problems turned out to be inefficient management practices.

Strangely enough, when that information came out, we where suddenly told that we would no longer be using Jira, and that a new product would be brought in to replace it.

In the mean time, all requests for data to be passed through Jira had to be sent to the management team, and we had our direct access removed.

What wasn't noticed was that as part of the stats calculation, the dev team had Jira poking data to a web hook, and this web hook was used to pass data to an end point on some internal servers, where we had code that created these reports automatically.

We started monitoring the web hook, and found that even though we where told that Jira was no longer used, it remained very much alive for a considerable amount of time longer (6+ months to be exact) and the wholesale abuse by upper management was just plain rampant with incorrect use.

Of course, it doesn't have to be something as complex as Jira.

If you want a low yield solution, you could use a google-docs spread sheet, and the GDocs notification API, to track tasks/tickets/bugs/feature requests etc.

GDocs itself can now issue web-hooks and all sorts of things.

Couple that with Git and/or Github and some hooks that trigger when code is committed to your repository, and you've got a reasonably efficient home brew system, that can record a surprising amount of data.

In general however, out of 100% of a products natural lifetime, the split between greenfield dev and maintenance is generally 20/80, most of the cost in the ALM (Application Lifetime Management) cycle is taken up on maintenance and support costs.

There's no such thing as spending too much time fixing bugs, beacuse it's simply not possible to write bug-free code.

Good testing and continuous integration policies will reduce the deficiet , but you'll never completely eradicate it.

Anyone who believes otherwise (IMHO) doesn't have enough knowledge to make an acurate judgment, or is blind (The more usual case) to just how difficult it actually is to write software.

If your manager is up for it, and some of them are, then you might want to suggest that he shadows you for a day, so he can see exactly what you do and how you do it.

Iv'e worked in a few companies where this kind of work was actively encouraged, with upper level staff shadowing lower level staff, and vice-versa, it can be a really, really good learning experience for both involved parties.

share|improve this answer
2  
"There's no such thing as spending too much time fixing bugs" - what a load of crap. If you spend enough time fixing bugs that your company goes under because it couldn't stay competitive in the marketplace (because you were fixing bugs rather than doing stuff), you spent too much time fixing bugs... –  Telastyn Jul 9 at 20:20
    
And the alternative? - You don't spend enough time fixing bugs, and your app crashes, burns and your competitor takes all your custom, effectively pushing you out of the market place. The trick (and the hardest part of all of this) is to actually find an acceptable balance. –  shawty Jul 9 at 20:48
1  
No i agree, but that's my own opinions coming through there, because I genuinely believe in this day and age, the art of proper debugging is becoming a lost art. Too many of us, rely far too much on things like unit tests, which IMHO provide too much false security. I'm not saying unit test should be abolished, but I am saying there's not enough proper debugging and bug fixing practices performed any more, because of it. This is turn leads to managers (As described above) believing that Bug fixing is not required, and as a result we genuinely don't (Again IMHO) do enough of it. –  shawty Jul 9 at 21:11
2  
unit tests and debugging are different arts used for different problems. Though solving the "is our code correct" problem better prevents the "why is my code broke" problem. All things being equal, I'd rather people be good at making correct code than identifying root causes. –  Telastyn Jul 9 at 21:19
1  
Now that point you have my full agreement on. It's a sad fact that in today's industry many programmers do treat it as just another 9 till 5 job, where they clock in, bang out code until home time and clock out. Back in the day, devs took immense pride in writing good, solid, well tested code and spent time thinking about it before going anywhere near a keyboard, you see very little of that in this day and age. –  shawty Jul 9 at 21:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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