Did I miss any techniques that you find useful?
When I linked this on del.icio.us just now, I added:
6. "It's a feature."
Discussion on:
View:
Show:
Virtual Serial Port Kit creates pairs of virtual serial ports in your system which are virtually connected to each other. Physical null modem cables are not required. You can connect any number of virtual port pairs. It's very useful for debugging.
The last time I had to do that was when we
invented our own file transfer protocol to
get from RSX-11M to Xenix before Kermit was
available.
invented our own file transfer protocol to
get from RSX-11M to Xenix before Kermit was
available.
techniques.
Debugging backwards seems a pain, a lot less effort to be sure it's in routine X, however it always works, guessing is less efficient, when you guess wrong.
What I like to do is bracket the error, it does make an assumption of basic linearity, but if you can bracket the the execution from definitely good to definitely bad, you can home in where things are going out of wack. It also stops you spending hours to find out that say some other program put what should be / (or was assumed to be) an illegal value in the DB, or other input.
My number 5 (Refactor should always be the last thing you try) , is if what you currently know suggests rarely seen events such as witchcraft or a micro black hole in orbit around a memory chip, you've probably gone wrong. Sort of a re-application of point two.
Don't be afraid to start again if you've confused yourself. It happens to us all.
Oh and apply what you learnt from problems you've solved to problem avoidance.
Side effects, global variables and misleading names being classics.
Debugging backwards seems a pain, a lot less effort to be sure it's in routine X, however it always works, guessing is less efficient, when you guess wrong.
What I like to do is bracket the error, it does make an assumption of basic linearity, but if you can bracket the the execution from definitely good to definitely bad, you can home in where things are going out of wack. It also stops you spending hours to find out that say some other program put what should be / (or was assumed to be) an illegal value in the DB, or other input.
My number 5 (Refactor should always be the last thing you try) , is if what you currently know suggests rarely seen events such as witchcraft or a micro black hole in orbit around a memory chip, you've probably gone wrong. Sort of a re-application of point two.
Don't be afraid to start again if you've confused yourself. It happens to us all.
Oh and apply what you learnt from problems you've solved to problem avoidance.
Side effects, global variables and misleading names being classics.
(another way to say what you said)
Thanks, Tony, I quite forgot to mention that technique. It sort of goes hand in hand with making the problem smaller.
Yes, when you find yourself ready to believe that quark mechanics or the phase of the moon really are significant to the behavior of a script, it's definitely time to question assumptions.
Another good point on misleading names. I don't know how many times I've tried to eyeball a problem and been taken in by two variable names that are similar but not identical. It's when you step over the statement that assigns the variable, yet it doesn't change, that you say "the language is broken!" and then you realize your mistake.
Thanks, Tony, I quite forgot to mention that technique. It sort of goes hand in hand with making the problem smaller.
Yes, when you find yourself ready to believe that quark mechanics or the phase of the moon really are significant to the behavior of a script, it's definitely time to question assumptions.
Another good point on misleading names. I don't know how many times I've tried to eyeball a problem and been taken in by two variable names that are similar but not identical. It's when you step over the statement that assigns the variable, yet it doesn't change, that you say "the language is broken!" and then you realize your mistake.
distinguish names, but worse still is bad names.
Absolute classic eventually pinned down the other day
FindBySchedule(Schedule aschedule)
FindByScheduleName(String aschedulename)
No way you'd figure the first one sets up a predicate using aschedule.ScheduleName is there, I mean that would be outright lunacy would n't it?
Test Build Test, please boss just try it, please....
Needless to say this was about 32 fathoms deep in the application, and I must have missed it more than once as well.
Gone all the way through the code, there is no bug, it's those little blue f'kers from Rigel playing jokes again.
Another thing to learn from debugging, it is going to happen, plan for it....
Keep it simple isn't stupid.
Being too clever is.
Absolute classic eventually pinned down the other day
FindBySchedule(Schedule aschedule)
FindByScheduleName(String aschedulename)
No way you'd figure the first one sets up a predicate using aschedule.ScheduleName is there, I mean that would be outright lunacy would n't it?
Test Build Test, please boss just try it, please....
Needless to say this was about 32 fathoms deep in the application, and I must have missed it more than once as well.
Gone all the way through the code, there is no bug, it's those little blue f'kers from Rigel playing jokes again.
Another thing to learn from debugging, it is going to happen, plan for it....
Keep it simple isn't stupid.
Being too clever is.
More than a few times I've outwitted myself on revisiting old code in which I created a clever algorithm that wasn't obvious to the reader. I either eschew those now or comment them to death, er I mean, to clarity.
I hate it when the person on the other end keeps asking me for more information on how to reproduce the error that I am getting. The impression I get is that the person on the other end has not even tried to check if there is a problem. Most of the times, I have seen that if the person at other end is candid enough to admit to me that he does not have the infrastructure for testing or he has tested and cannot reproduce the problem, it leads to a faster solution. If the person on the other end can reproduce the problem, then he can find the solution, if he cannot reproduce the problem, it might be something peculiar in my setup and we stop looking for bugs in the software and start looking for environmental issues.
If the person on the other end just keeps asking me for more information and steps without giving me a feedback, it is bad form. Clear and honest communication with the client is very important in problem solving. I view this communication as the first step in debugging any issue. I have been on both sides of the table. Timely and clear communication is appreciated by all the customers.
If the person on the other end just keeps asking me for more information and steps without giving me a feedback, it is bad form. Clear and honest communication with the client is very important in problem solving. I view this communication as the first step in debugging any issue. I have been on both sides of the table. Timely and clear communication is appreciated by all the customers.
... dealing with support people who just keep asking what seem to be stupid questions or putting me through exercises that I know will lead nowhere. That usually occurs when I know more about the software than they do, and they're grasping for straws because they have no idea where to look.
On the other hand, I have sometimes been surprised by the result of going through the motions with them. As good as I am (and I'm damn good if I may say so), I'm not above making false assumptions myself, and these are often shaken out by taking a very methodical approach to a problem. So in spite of my impatience, I'll usually agree to rule out my stupidity first.
On the other hand, I have sometimes been surprised by the result of going through the motions with them. As good as I am (and I'm damn good if I may say so), I'm not above making false assumptions myself, and these are often shaken out by taking a very methodical approach to a problem. So in spite of my impatience, I'll usually agree to rule out my stupidity first.
get at least one request for confirmation of how to produce a fault, if it can't be re-produced. I agree you explain why you are asking for it though.
This isn't because I think you are a dumbass, who forgot to mention something.
Of course if it turns out that in your horror at the error dialog, you did miss out step D, then we have to go round the whole cycle again.
Enviromental issues are usually unbelievably trivial, did you say XP Home ?.
To complete b'stards.
There may be a tendency to hope it isn't one of these so much , youll just ask one more time. May be it only happens when he's drinking tea, the blinds are half drawn, and a passing duck honks.
This isn't because I think you are a dumbass, who forgot to mention something.
Of course if it turns out that in your horror at the error dialog, you did miss out step D, then we have to go round the whole cycle again.
Enviromental issues are usually unbelievably trivial, did you say XP Home ?.
To complete b'stards.
There may be a tendency to hope it isn't one of these so much , youll just ask one more time. May be it only happens when he's drinking tea, the blinds are half drawn, and a passing duck honks.
that I have found, is to look for a core file.
even if I can't reproduce the error if the app left a core, I have the exact state of the machine when it crashed.
[ assuming a fatal error and app crash on that ]
on my own apps that I have written, until it's on a second release, I leave debug code in so that errors can give useful information instead of generic messages that are useless.
the worst I saw for useless generic error messages was installing kylix 3 on a linux system running the 2.6 kernel, error code 10. Borland was no help at all. I had to struggle for a week to figure it that kylix 3 would not work with any linux kernel newer than the 2.4 series. What a wast of time and effort on Borland's part, to write an app that couldn't b used for more than a year or two before it wouldn't install at all.
even if I can't reproduce the error if the app left a core, I have the exact state of the machine when it crashed.
[ assuming a fatal error and app crash on that ]
on my own apps that I have written, until it's on a second release, I leave debug code in so that errors can give useful information instead of generic messages that are useless.
the worst I saw for useless generic error messages was installing kylix 3 on a linux system running the 2.6 kernel, error code 10. Borland was no help at all. I had to struggle for a week to figure it that kylix 3 would not work with any linux kernel newer than the 2.4 series. What a wast of time and effort on Borland's part, to write an app that couldn't b used for more than a year or two before it wouldn't install at all.
Another piece of advice: let it die.
Remove or disable code that catches errors so you get the full advantage of your debug environment. Or at least catch a class of exception that gives you enough information, if there is one.
Remove or disable code that catches errors so you get the full advantage of your debug environment. Or at least catch a class of exception that gives you enough information, if there is one.
EXPECT PROBLEMS. A fundamental principle is that both the customer and the supplier (internal IT shop and end-user population) - supplier and end-user should expect that problems WILL occur. When you DO expect problems to occur, you will set up environments to automatically capture significant problem-solving data for the end-user to have available to convey to the problem-solving department. I have a lifetime career devoted to making this happen. My commercial message and MY website/business is: www.FirstFaultProblemResolution.com
Yes, if you ANTICIPATE that problems will occur you can ensure that a major head-start can be launched immediately. Often believe it or not, boys and girls, ladies and gentelmen, you CAN solve a problem on its FIRST occurrence. IMHO.
Yes, if you ANTICIPATE that problems will occur you can ensure that a major head-start can be launched immediately. Often believe it or not, boys and girls, ladies and gentelmen, you CAN solve a problem on its FIRST occurrence. IMHO.
One thing that helps me on a really difficult bug is to flowchart the section of code where the bug is occurring. It doesn't have to be a detailed chart, but diagramming the process helps me to spot irregularities in the code.
I haven't drawn a flowchart in decades, but I often visualize problems in my mind. I can see how putting it on paper could help sort the fuzzy bits out.
was the bane of my existence in the first computer science course I took, back in high school.
hand me the assignment, and I wrote the code, but I could not draw up a flow chart at all.
one classmate could flowchart like a demon, but couldn't put it into code.
we got together to help each other out
hand me the assignment, and I wrote the code, but I could not draw up a flow chart at all.
one classmate could flowchart like a demon, but couldn't put it into code.
we got together to help each other out
Dry runs, have on occasion
If it works though, it's good.
We all have our ways of visualising what's going on maybe the fuzziness and the demonstrable lack on one right answer is why academia seem to skip debugging / fault finding as though something useful couldn't be taught.
If it works though, it's good.
We all have our ways of visualising what's going on maybe the fuzziness and the demonstrable lack on one right answer is why academia seem to skip debugging / fault finding as though something useful couldn't be taught.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
