All Posts

The Art of debugging

An average developer is someone, who can write code, once explained what to do and how to do it.
A good developer is someone, who can implement something, once told what to do (he can figure out the how part)
An awesome developer given business goals,  can also figure out what to do.
But a great developer is someone who can just figure out what’s wrong with some one else’s code quickly. I consider ‘Art of debugging’ as the Zenith of one’s development prowess, because a great debugger can mean meeting product deadlines without compromising on quality.
Here are some of my tips if you want to be a great developer.
1. Identify the problem
Lot of times the real problem is wrapped under multiple layers of wrong design and hence wrong implementation. Which means that the natural instinct of any developer is to fix the symptopms ( login not working) rather than attacking the real issue.(wrong database architecture?). It takes lot of courage to admit a bug with the design at late stage cause everyone wants quick results. But as we find out time and again, it saves lot of time if you attack the real problem rather that keep on fixing symptoms.
2. Look at different ways to solve- don’t be afraid to rewrite
Once you identify the problem, always go for the “right” way to fix it rather than seemingly “quick” fix. Quick fixes have habit of generating plenty of side effects. This sometimes means rewriting the code and your customer/ manager may be pushing you really hard to show quick results. Be patient and fix it correct way, it will avoid lot of heartburn and disappointments compared to the quick and dirty solutions ! But this is much easier said than done.
3. Estimate collateral damage
This is an art. In absence of documented and updated design (which is the case with 80-90% of world’s software), it needs deep knowledge of how software works to estimate what all you may “break” by changing something else in the system. You can develop this knack over years with experience. But this is the ‘real’ thing.
4.Write test cases
This comes before you actually go on and implement. It’s always important to know how you can be “sure” your fix solves problem and does not cause side effects. I have always found it very useful to write a short test document/ white box tests before implementing so I know the “target”. It’s also easy to track progress with this approach.
5. Document then implement
If you are a good developer it will come easy to you. But in general document what changes you want to make before you actually start coding. Never find out things incrementally. If while implementing you come across an unforeseen issue, go back to step 1 rather than continuing to incrementally change the nature of fix.
6. Test well
Again all you need to do is to be careful while testing so your “fix” stays when deployed in the system
And if you are really that special someone, you will share the root cause, your analysis, you fix and test procedure for someone who will look at it after you. This will make life really easy for some one else working on the system.

Comments (4)

  1. I would argue that your “Bonus” section is mandatory to go home proud, but my standards are high. Unless you fix the root cause and confidently share you results via speech and or documentation you will always be an average software engineer in any industry sector.

  2. Good Write Up !!! Thx for sharing !!!

  3. Very good article. I like the simple differentiation between developers mentioned in the beginning.
    The great developer as you have mentioned above, has to constantly take the right decision while finding the bug and fixing the bug. He needs to decide exactly what needs to be changed in the system, as well as how much change is needed. Anything less or anything more affects the release cycle of the software.

  4. Thanks Rishi, Thanks Raghuram, @Paul , to each his own ..:-)

Comment here