Take the 2-minute tour ×

What is the approximate ratio of time you typically spend debugging high-level versus low-level bugs?

For the purposes of this discussion, high-level bugs are things like incorrect algorithms, bad assumptions about input data and/or operating environment, cases that were overlooked in the initial implementation of something, forgetting to deal with boundary conditions/edge cases, etc. For the sake of discussion, they can also include poor design decisions that introduce limitations into the code and are non-trivial to change, even though this is stretching the definition of a bug. In other words, high-level bugs are bugs caused by not meaning what you should have meant.

Low-level bugs are things like memory management and corruption problems, null pointer dereferences that aren't caused by high-level bugs, subtle syntax errors that get past the compiler, off-by-one errors when doing stuff with arrays, etc. In other words, they are bugs caused by not coding what you meant.

Also, for the sake of comparison, what language(s) do you primarily use and what type of programming do you primarily do?

share|improve this question
My Apologies.But this might get closed soon under "Subjective and argumentative" –  bludger Nov 1 '09 at 21:01
@Ravi - Nah. Not argumentative. –  Michael Petrotta Nov 1 '09 at 21:09
Your examples for low-level and high-level bugs seem contradictory to me. For instance, you mention a non-handled edge case as a high-level bug, but both a null pointer exception and an off-by-one error in a loop as low-level bugs. I consider all three to be edge cases of the algorithm often not specifically mentioned in the spec, or what you would call high-level bugs. All are usually caused by failure to test properly on the part of the developer. –  gooli Nov 1 '09 at 22:01
If you want to reduce time spent debugging, look into Test-driven development (or at least unit testing). –  TrueWill Nov 2 '09 at 3:28

3 Answers 3

By your definition almost all of the bugs I see are "High-level" bugs.

I work in C# using the .net framework. The framework takes care of almost everything you define as low-level bugs.

share|improve this answer
This is just what I was going to say. If you're spending more than 2% of your debugging time on what are here classified as "low level" bugs, then perhaps it's time to upgrade your toolchain! :) –  Brian Nov 1 '09 at 21:31

Low level bugs are usually fixed by the compiler only.So, first look at the high level bugs and then low level bugs(if needed at all).Because trying to construct a building and thinking of making strong walls on a weakly constructed base is totally useless.

Its funny but true.Think about it.

share|improve this answer
Debugging...Oh I remember my question.. stackoverflow.com/questions/1592457/… –  bludger Nov 3 '09 at 9:56

If I understand your question correctly, you separate the bugs into two types - those that are caused by poor programming practice and those that are caused by problems in the design and spec. Assuming my understanding is indeed correct, I would say that as a developer I spend more time tracking down low level bugs, especially if they are hard to reproduce (Yes, damn multi-threading bug that only happens in production, I'm talking to you!). Design- and spec-level bugs, on the other hand, usually cause serious delays for the project, but are easier to reproduce and to locate in the code.

share|improve this answer
But whats the use if you went wrong at design itself or you considered a wrong algorithm? –  bludger Nov 2 '09 at 5:14
In the kind of business software that I work on these days there is quite a bit of business logic that makes very little sense. Sometimes when I try to extrapolate the behavior in edge cases I get it wrong - i.e. not what the product people want. That's the kind of thing I mean there, and not a completely wrong design. –  gooli Nov 2 '09 at 6:17

Your Answer


