Thread: Can a debugger be used too much?

Originally Posted by c_weed

Is it bad to use a debugger too much?

Different people are likely going to have different opinions about this, but I don't think so. Certainly, there are situations where it won't help so much. But that's a basic application of the "use the right tool for the job" rule.

I once took a math course where the prof had his background in computer science and he was saying the worst invention was the interactive terminal because before a programer would have to think about the program they are writing as they couldn't just try it out.

That's just silly. You still have to think about your program before you write it. Otherwise it's going to hurt you down the road.
But might see where he's coming from if we apply that to newbies. But the real solution is to teach them to do it properly instead of blaming inventions.

I remember back when I used to have to actually compile the source file each time to see any errors, now IDEs like Visual Studios tell you any errors as you type. Can it be made too easy on the programer?

The effect is the same, so what does it matter?

Originally Posted by c_weed

I once took a math course where the prof had his background in computer science and he was saying the worst invention was the interactive terminal because before a programer would have to think about the program they are writing as they couldn't just try it out.

Even before the invention of the interactive terminal, it was still possible for a programmer to just try it out, though it would have been more tedious. Rather, the worst invention was the computer because before that a programmer would have to think about the program they are writing as they couldn't just try it out.

Originally Posted by c_weed

Is it bad to use a debugger too much?
Can it be made too easy on the programer?

The answers to those questions are most definitely:
NO, and NO.

Originally Posted by c_weed

Is it bad to use a debugger too much?

Anything considered "too much" by definition is not as good as it could be.

Using a debugger to augment a good development approach is a good thing. With a decent development process and good code organisation, when something doesn't work, the developer will often have a reasonable idea of where the problem is - which means they can target their use of the debugger better in order to really pin a problem down. Once they've done that, they can fix it.

However, a debugger can also be used by people with shocking development processes (say, those people who sit down at a keyboard and tap away without much thought, in the hope their code will magically work). Those people will love a debugger, because it does help find problems more easily. However, the debugger also causes an illusion for those people - they believe they are getting things working faster and better but, on average, they are not. Sometimes they will get lucky, and find the problem quickly, but more often they will take longer than a person who thinks about their software structure, their code, and follows a reasonable process. In that way, using a debugger can be very deceptive.

Originally Posted by c_weed

I once took a math course where the prof had his background in computer science and he was saying the worst invention was the interactive terminal because before a programer would have to think about the program they are writing as they couldn't just try it out.

That's an exaggeration, but that prof has a point. Before computers, it was necessary for scientists of all disciplines to reason out a solution to a problem. Computers made it easier for people who can't be bothered thinking through a problem to tackle it by trying things over and over (and over, ad nauseum) again. Such processes are inefficient, both of the person's time, and use of the computer (I've lost track of the number of times I've seen people happy to write a bit of haphazard code to search for a solution to a problem using several hours or weeks of computer time which - if they had thought through it - they could have formulated the exact solution in a few minutes.

The phenomenon (people searching for a solution haphazardly, instead of thinking through a problem) also applies to software development. It is (almost) always as easy to use a debugger in a poor, haphazard, process as it is to use the debugger in a thoughtful, disciplined, process.

Originally Posted by c_weed

I remember back when I used to have to actually compile the source file each time to see any errors, now IDEs like Visual Studios tell you any errors as you type.

To be precise, that is something different from a debugger. It is the IDE (possibly with help of the compiler backend, depending on IDE) highlighting syntax errors. Avoiding syntax errors is a good thing, but doesn't provide any confidence that code does what it is intended to do. No IDE is capable of reading a developers mind, and turning a series of ambiguous thoughts (of the typical human) into well-crafted code that does what the developer wanted even if they didn't think about it clearly. That might change in future, but I'm not holding my breath waiting.

Originally Posted by c_weed

Can it be made too easy on the programer?

Yes, it can be.

For a developer who has good technique and follows a sensible thought process, making things easier will almost always be beneficial - it allows the person to do more useful work, more quickly, and with less stress. Everyone wins from that: the developer enjoys the job more, the developer's employer gets better product without paying a lot of money for false starts, the end user of the software gets a better product at a fair price. Even the supplier of a good tool that makes a developer's job easier benefits - the developer and/or the developer's employer will be a good customer who will keep using and licensing their product and its updates.

However, there is less benefit in making the job easier for a bad developer. With some good luck, making life easier for a bad developer will help them produce better product. Unfortunately, making life easier for a bad developer can simply mean they churn out more bad product, or it can help them obscure (until it is too late) the bad product.

Originally Posted by iMalc

The answers to those questions are most definitely:
NO, and NO.

I would argue here. Before I turn on a debugger, I always look at the source code first to check if I understand how it works and to find the potential bug just by staring at it. After a short while, if that does not help, I think of the following reasons:
1. I don't really understand what my code does. This is a hint to refactor, so that it is clear what the code actually does.
2. My code is not covered enough by unit tests - did I miss a test case? If so, when I finally find the issue (either with debugger or just by staring at the source), I cover it with a new test case.

Jeez, it's programming. Not Christ bearing the Cross. Easy is better.

People who can't think straight are doomed regardless of the tools they use. I don't understand why you'd base your decision on what an incompetent person might do -- unless you're incompetent yourself I don't see why it matters.

There are some problems a debugger can't find, particularly if the problem is in a closed-source library or the operating system itself. There are situations where using a debugger will change the behavior of a program, due to timing variation. For pretty much any other situation, a debugger is a powerful tool that can't be used too much. It's not a crutch, any more than a power saw is a crutch for carpenters. Sure, you can do it the hard way, by adding console output to inspect the values of variables, but it's a waste of time. A debugger is a common tool, that is typically integrated with the development environment, that allows a programmer to make a better product, in less time. It's not possible to use it too much. It's not cheating to use better tools.

I don't understand why you'd base your decision on what an incompetent person might do -- unless you're incompetent yourself I don't see why it matters.

O_o

*clink*

Hear, hear!

Soma

Originally Posted by Elkvis

There are some problems a debugger can't find, particularly if the problem is in a closed-source library or the operating system itself. There are situations where using a debugger will change the behavior of a program, due to timing variation. For pretty much any other situation, a debugger is a powerful tool that can't be used too much. It's not a crutch, any more than a power saw is a crutch for carpenters. Sure, you can do it the hard way, by adding console output to inspect the values of variables, but it's a waste of time. A debugger is a common tool, that is typically integrated with the development environment, that allows a programmer to make a better product, in less time. It's not possible to use it too much. It's not cheating to use better tools.

Huh? It looks like you didn't get my point at all. I don't say that you should avoid using debugger at all. If it is the right tool and it will do its job, you should definately use it. BUT if you keep using it more and more often, it is a symptom that your code is just poorly designed. It's a code smell. It's a measurement of quality.

And not using debugger only to sweep the poor quality of code under the carpet is probably even worse.

Originally Posted by kmdv

Huh? It looks like you didn't get my point at all.

If I were responding to your post, I would have quoted you. I was offering my opinion to the OP. No need to be defensive here.

Originally Posted by brewbuck

I don't understand why you'd base your decision on what an incompetent person might do -- unless you're incompetent yourself I don't see why it matters.

The demand for good developers often exceeds supply, but there is often a larger pool of applicants for jobs who have lesser ability. It's not actually a big step from arguing that tools which can help competent but expensive programmers be more productive can help less competent but less expensive developers do better work.

And, let's face it, a lot of developers do sloppy work and use a debugger to find and patch over problems.

And, let's face it, a lot of developers do sloppy work and use a debugger to find and patch over problems.

O_o

I don't think I've ever seen that.

I see plenty of sloppy coders, but I don't see sloppy coders competently using a debugger.

Sure, misuse of a tool can actually make code worse.

Rephrasing, why limit tool selection on the off chance someone that awful comes along unless you are also that awful?

Soma

Originally Posted by phantomotap

O_o

*clink*

Hear, hear!

Soma

Obviously, I've been thinking about the last little debate we had. And I realized that I have held the above opinion for quite some time, but somehow forgot it in my frustration. So thanks for providing a guard rail.

Originally Posted by phantomotap

I see plenty of sloppy coders, but I don't see sloppy coders competently using a debugger.

I wish I could make the same claim.

Originally Posted by phantomotap

Rephrasing, why limit tool selection on the off chance someone that awful comes along unless you are also that awful?

I did not suggest limiting tool selection. I responded to the original question about whether it is possible to overuse a debugger.

Although, thinking about it, the word tool has a slang meaning: a fool or cretin. A sloppy programmer may therefore be characterised as a tool, and represent a scenario in which I would probably advocate limiting tool selection.