Reading Time: 2 minutesReproduce the problem
A lot people ignore it or treat it too lightly. But this is the first step. Make sure the problem appears consistently under the user-described situations; and the symptom is exactly as the user reported. Otherwise you will try to solve the problem “you see”, not “the user sees”. Maybe you will be lucky enough to “see” the same problem as “the user see”. But more likely you will be will be solving another problem, or a related problem. And the next day (week, month), the user will come back and shout at your boss: how come the problem you claimed “fixed” still exisits? You know how embarassing you will be at that time.
Simplify
After “reproduce the probelm”, the next step is to simply. By “simply” I mean the real problem is ususally complicated, and it will take a lot time to run through debugger. The goal here is to simply the problem as much as possible. For example: delete unrelated parts from the raw data. You should be very careful in doing this too. Because you could eliminate the problem area in doing this, i.e., the problem will be gone if you don’t simplify properly.
Find the cause
Here comes the real run. After all the analysis, time to jump into the code. It’s why we progrmmers are paid for, right? But it is also the most difficult part. I am still puzzled by the problem I mentioned at the beginning. Hopefully by stepping through the code, talk about the algorithm with the guru in your team, even ask a second pair of eyes to take look, we can nail the problem.
Fix or ask appropriate party to fix
Then comes the politics part. I have to admit this is not my specialty. Luckily if the mistake is made by yourself, and you know how to fix. Life is good. But a lot of times the mistake could be made by somebody else, maybe some code written by another team member, or even a piece of software created by 3rd party. In these cases, you need to demonstrate the problem to responsible parties, bugging (asking) the people for a quick fix. Meanwhile your sales team or customer are already screaming.
Workaround
Luckily, sometimes you can find a workaround the customer like. That provide cushion time for you or your team to work out a fix.
As software developer finding and fixing the bugs (defects in software) is just a way of life. I have been debugging (find the cause) a tough problem lately. During debugging sometimes I wished I would have another job. But when I solved a real problem, the satisfaction can not be easily described by words. I bet a lot of people in software developement have similar experience. I want to share some of the general steps I take during debugging.
A lot people ignore it or treat it too lightly. But this is the first step. Make sure the problem appears consistently under the user-described situations; and the symptom is exactly as the user reported. Otherwise you will try to solve the problem “you see”, not “the user sees”. Maybe you will be lucky enough to “see” the same problem as “the user see”. But more likely you will be will be solving another problem, or a related problem. And the next day (week, month), the user will come back and shout at your boss: how come the problem you claimed “fixed” still exisits? You know how embarassing you will be at that time.
After “reproduce the probelm”, the next step is to simply. By “simply” I mean the real problem is ususally complicated, and it will take a lot time to run through debugger. The goal here is to simply the problem as much as possible. For example: delete unrelated parts from the raw data. You should be very careful in doing this too. Because you could eliminate the problem area in doing this, i.e., the problem will be gone if you don’t simplify properly.
Here comes the real run. After all the analysis, time to jump into the code. It’s why we progrmmers are paid for, right? But it is also the most difficult part. I am still puzzled by the problem I mentioned at the beginning. Hopefully by stepping through the code, talk about the algorithm with the guru in your team, even ask a second pair of eyes to take look, we can nail the problem.
Then comes the politics part. I have to admit this is not my specialty. Luckily if the mistake is made by yourself, and you know how to fix. Life is good. But a lot of times the mistake could be made by somebody else, maybe some code written by another team member, or even a piece of software created by 3rd party. In these cases, you need to demonstrate the problem to responsible parties, bugging (asking) the people for a quick fix. Meanwhile your sales team or customer are already screaming.
Luckily, sometimes you can find a workaround the customer like. That provide cushion time for you or your team to work out a fix.