I'm trying to find a research answering a question: "How much time developers spend on development vs debugging?". I found several interesting links on the Net but they are little too old.

This 2002 RTI study states that software bugs cost U.S. economy $59.6 billion annually. And in this book Beizer (1990) reports that of the labor expended to develop a working program, 50% is typically spent on testing and debugging activities. I've seen this number is 80% but can't find the link.

  • 1
    Just to make it clear, debugging is a natural part of development, and its cost must be factored in - not "something that costs the U.S. economy $X bln". It's like you said "planes landing in airports cost the U.S. economy $X bln." as if you could cut costs by increasing number of take-offs and reducing number of landings.
    – SF.
    Jul 11, 2011 at 13:01
  • 1
    @SF agreed. But in case of debugging you can decrease time spent on it by simply knowing the proper techniques and preventing bugs at the beginning. Which is not the case with landing.
    – Anvaka
    Jul 11, 2011 at 14:01
  • You should always observe best practices, sure. Also, you can reduce the number of bugs in shipped product. But the most efficient bug preventing techniques are more costly and time-consuming than bug fixing itself.
    – SF.
    Jul 11, 2011 at 15:03

3 Answers 3


In Rapid Development: Taming Wild Software Schedules, Steve McConnell cites a few articles by Capers Jones, Barry Boehm, Thomas Glib, and Philip Papaccio. Some of the figures he references are:

  1. Reworking defects in requirements, design, and code consumes 40-50% of the total cost of software development. (Boehm, Barry W. 1987. "Improving Software Productivity." IEEE Computer, September: 43-57.; Jones, Capers, ed. 1986. Tutorial: Programming Productivity: Issues for the Eighties, 2nd ed. Los Angeles: IEEE Computer Society Press.)

  2. Every hour spent on defect prevention will reduce repair time by 3-10 hours. (Jones, Capers. 1994. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Yourdon Press.)

  3. Reworking a requirements problem once the software has shipped costs 50-200 times what it would take to rework during requirements. (Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering, vol. 14, no. 10 (October): 1462-1477.)

  4. 60% of all defects usually exist at design time. (Glib, Tom. 1988. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley.)

Some of these sources deal with a difference in time. I don't have any hard evidence to back this up (it might be in the papers), but I would suspect that a good chunk of the total cost is paying the developers for their time, so using either time or cost would be a valid comparison from a project management perspective. I would suggest reading the papers, though.


There isn't yet a lot of research on this very topic. Joel and Jeff talk about this in the Stack Exchange Podcast, Episode #09. Their guest is a guy who has done some study here, and is also pushing to apply more hard engineering practices to software engineering.

So, may answer is, as you've found there isn't a lot of research yet, but that podcast episode can point you to other people and resources who are really starting to ask this question.


The question adresses so many developers, languages, different skill levels, jobs and tasks - you need a very big number, to get everybody in, and then it will maybe not fit for this language or that, for mature developers or beginners. So to build your own statistic: have a random alarm once per day, and note, what activity you were performing, when the alarm went off. After 100 alarms, you have a rough estimation which might not work for others, but for you.

  • 1
    I don't understand this. There's a significant body of research on software quality, especially with regards to cost and effort. I could pull a half dozen books from my bookshelf alone that have chapters or sections on software quality or controlling costs of software projects with a mention of defect elimination or reduction.
    – Thomas Owens
    Jul 11, 2011 at 2:18
  • 1
    Having numbers doesn't mean that those numbers do apply for your project. Is it similar? Was the data representative? How should it be in such a fast developing aerea as programming? A book from 1994 has no data about Java, Ruby, Scala, few data on development for smartphones, nearly nothing about the internet. Will its conclusions fit for today? You can assume that it will, and you can asssume farming statistics will fit as well. Jul 20, 2011 at 17:44

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