views:

105

answers:

3

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?

+1  A: 

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.

Shiraz Bhaiji
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
A: 

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.

Ravi
Debugging...Oh I remember my question..http://stackoverflow.com/questions/1592457/how-to-debug-a-program-without-a-debugger
Ravi
A: 

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.

gooli
But whats the use if you went wrong at design itself or you considered a wrong algorithm?
Ravi
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