Home » Software Development » Are Debuggers Crutches?

About Dalip Mahal

Dalip Mahal
Dalip is a principal consultant at Accelerated Development and has worked his way through all aspects of software development. He started as a software engineer and worked his way through engineering and product management.

Are Debuggers Crutches?

Woman-on-Crutches-103x300Debuggers have become powerful tools, but like a drug have we become too dependent on them? Since poor developers spend 25 times more time in the debugger there is a likelihood that people are zoning out in the debugger instead of using other methods.

Defects are common, but they are not not necessary.  They find their way into code because:

Defect correction is only possible if you understand the code pathways, debuggers are not the best way to do this.
Debuggers are commonly used by developer’s to understand a problem, but just because they are common does not make them the best way to find defects.  I’m not advocating a return to “the good old days” but there was a time when we did not have debuggers and we managed to debug programs.

Note: in embedded systems it is very hard to get feedback if you do not use a debugger (or hardware debugger).  This article is not addressed to embedded developers who rarely have an alternative to a debugger.

Avoid Defects

ShowCover.aspxThe absolute best way to remove defects is simply not to create them in the first place. You can be skeptical, but things like  the Personal Software Process (PSP) have been used practically to prevent 1 of every 2 defects from getting into your code.  Over thousands of projects:

The Personal Software Process increases productivity by 21% and increases code quality by 31%

A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. This huge waste could be cut in half if all developers focused on not creating defects in the first place.

Not only does the PSP focus on code planning, it also makes developers aware of how many defects they actually create.  Here are two graphs that show the same group of developers and their defect injection rates before and after PSP training.

PSP, defects per KLOC, before.PSP, defects per KLOC, after
Before PSP trainingAfter PSP training


Finding Defects

Unskilled-professionalUsing a debugger to understand the source of a defect is definitely one way.  But if it is the best way then why do poor developers spend 25 times more time in the debugger than a a good developer? (see No Experience Required!)

Poor developers spend a week in the debugger for every 2 hours that good developer does.

No one is saying that debuggers do not have their uses.  However, a debugger is a tool and is only as good as the person using it.  Focus on tools obscures lack of skill (see Agile Tools do NOT make you Agile)

If you are only using a debugger to understand defects then you will be able to remove a maximum of about 85% of all defects, i.e. 1 in 7 defects will always be present in your code.

Would it surprise you to learn that their are organizations that achieve 97% defect removal?  Software inspections take the approach of looking for all defects in code and getting rid of them. Learn more about software inspections and why they work here:


Software inspections increase productivity by 21% and increases code quality by 31% .

Even better, people trained in software inspections tend to inject fewer defects into code. When you become adept at parsing code for defects then you become much more aware of how defects get into code in the first place.

But interestingly enough, not only will developers inject fewer defects into code and achieve defect removal rates of up to 97%, in addition:
Every hour spent in code inspections reduces formal QA by 4 hours.


As stated above, there are times where a skilled professional will use a debugger correctly.  However, if you are truly interested in being a software professional then:

  • You will learn how to plan and think through code before using the keyboard
  • You will learn and execute software inspections
  • You will learn techniques like PSP which lead to you injecting fewer defects into the code

You are using a debugger as a crutch if it is your primary tool to reduce and remove defects.

Related Articles

Want to see more sacred cows get tipped? Check out:


Make no mistake, I am the biggest “Loser” of them all.  I believe that I have made every mistake in the book at least once!



Reference: Are Debuggers Crutches? from our JCG partner Dalip Mahal at the Accelerated Development blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....




  1. When I started programming with mainframe COBOL in the 1970s we did not have debuggers. We didn’t even have keyboards and monitors – we wrote our code on coding pads which was later punched onto cards and taken to the computer room. We received our results the next morning on a printed listing which was sometimes 100s of pages long, 132 columns per line, 66 lines per page. Due to the slow turnaround time we had to desk-check our changes by scrutinising the source code listing. This was relatively easy as it was contained in a single listing. Turnaround time – that time delay between writing down some code and seeing the results – was often 24 hours.

    This cannot be done today as we don’t work with printed listings, we work with monitors which sometimes can only display 20 or 30 lines at a time. We don’t have an entire program in a single file, it is split across hundreds of class files in different directories. Sometimes there is so much “magic” going on (such as autoloaders) that we cannot see what a program does simply by looking at the source code, we have to run it through an interactive debugger one line of code at a time.

    Yes, I spend more time in my debugger than I did years ago, but that is irrelevant as my turnaround time nowadays can be measured in seconds and not days.

  2. Tony, I am not saying that debuggers should not be used nor that they don’t reduce the turnaround time.

    One of the most enduring ratios for software development is the ratio of cost fixing of defects between: pretest, QA, and deployment. This ratio has been pretty constant at 1:10:100, that is it costs 100 times more to fix errors that slip through to deployment than those caught before the code goes to QA.

    Most people fire up the debugger after the code gets to QA and they notice that there are thinks that are not working. At this point the cost of fixing defects will be 10 times that of if they had been found before it got to QA, whether a debugger is used or not.

    My claim is that using effective pre-test strategies will not only reduce the cost of finding and fixing defects but will also reduce turnaround time. If a defect never gets to QA and deployment, it has got to have a shorter turnaround time…

Leave a Reply

Your email address will not be published. Required fields are marked *


Want to take your Java skills to the next level?

Grab our programming books for FREE!

Here are some of the eBooks you will get:

  • Spring Interview QnA
  • Multithreading & Concurrency QnA
  • JPA Minibook
  • JVM Troubleshooting Guide
  • Advanced Java
  • Java Interview QnA
  • Java Design Patterns