Improving Debugging Skills

[Akram Chotunukki]

Dear Jacquie

I am Java/J2EE developer from past 7 years. I worked on different kinds of java applications and j2ee/soa based enterprise applications and technologies like XML, SOA, WEB SERVICES, INTEGRATION PRODUCTS LIKE BPEL, ESB, WEB APPLICATIONS ETC.

Lot of times in our career we have to work on Maintenance Projects (aka brownfield development) since there are very few Development Projects (aka
greenfield development) opportunties we get. So we need to have good debugging skills and a good temperament to understand the code that already exists.

My experience at least is that I have given just source code and was asked to deliver the solution or fix bugs/code-issues etc. without being given any code documentation, application documentation
, requirements documentation, design documentation etc. and in these scenarios understanding the code can be challenging and daunting task as 80% of your project time you may be running the debugger for understanding the requirements and problem at hand. This approach is not acceptable but we have do not have choices most of the times. So a devloper who has good temperament in reading/debugging the code all day long can have good career in projects or companies. And I am not good at debugging the code which is the area I would like to improve upon.

I request you to give some suggestions on how to improve our debugging skills based on your vast industry experience. For debugging skills, I understand that it depends on individual
skills, his grasping skills, analytical skills etc. however I would like to know how to improve on them ? and any debugging tips from you ?
may be we can run eclipse debugger and understand but would like to hear from you the smart ways of understanding code written by others ? how to debug smartly code written by others ?
any tools, techniques, tips, hacks, strategies etc. we can use that increase our productivity in debugging code ? how to smartly debug web applications etc. ? etc.


Thank you in advance for your time on my thread.


- Akram

[arulk pillai]

May be you can draw some boxes and sequence diagrams to get a bigger picture of the requirements, design, technologies/frameworks, etc used. Knowing the bigger picture helps drilling down into details.

[Campbell Ritchie]

You should put your foot down and insist on being shown documentation. Tell your boss you can debug twice as fast if you know what the code is supposed to do. In fact, you might miss serious errors simply because you don't know the contract for each method or the invariants for each class.

[Jeanne Boyarsky]

Campbell Ritchie wrote:You should put your foot down and insist on being shown documentation.

And if there is no documentation to show you?

What you can do is make things better for the next guy. There may not be documentation now, but there's no reason there can't be in the future. Write down what you learn and start some documents. Get others to do the same.

[Campbell Ritchie]

Jeanne Boyarsky wrote:And if there is no documentation to show you?

Also, if you tell your boss the lack of documentation will cause mistakes, you have a defence if anything goes wrong.

[Burk Hufnagel]

Akram,
Presumably you get a description of what the problem is, and possibly what the code is supposed to do. If so, I think you might start writing unit tests against the suspected code to try and reproduce the error. Once you can reproduce a bug, you're on your way to fixing it. One benefit from this is that the unit tests you write become a kind of documentation for the next person who has to deal with the code.

The system you describe doesn't make a lot of sense, but in my experience I've found that documentation is one of the first things that gets cut when developers are under a too tight schedule. And, even if it does get written it usually isn't kept up to date - which can be worse because then the documentation you have is pointing you in the wrong direction.

I hope this helps some. Good luck,
Burk

[Akram Chotunukki]

I think I am still waiting for better suggestions from JavaRancher's.

Burk Hufnagel wrote:
The system you describe doesn't make a lot of sense
Burk

I agree that if you need to understand the as-is system you need to execute test cases/test data (if they already exists) but believe me, in my experience I have just given source code like as I said without any kind of documentation and even test cases/test data are not given. So whatever it takes to make the next developer life easier, I need to do that starting from scratch taking the initial pain to take to understand the code and deliver the solution with unit test cases, documentation etc. But I want some good debugging tips

[Burk Hufnagel]

Akram Chotunukki wrote:But I want some good debugging tips

1) Running a static analyzer like FindBugs against the code is a great way to find lots of bugs in pretty much any code base.

2) Part of the problem you're going to have is side-effects. Some are intentional and the rest of the code is expecting them, some are not and may be causing a bug elsewhere. The problem is that in your situation, you probably can't tell whether they were intended or not.

3) Sometimes the names of variables or methods doesn't describe them properly and can make it harder to understand what's going on. Rename them if possible.

4) Sometimes a method is doing too many things. Try to simplify it by extracting smaller coherent methods out of it and having it call them. Make sure to give the new methods a name that describes what they are doing.

Is that the kind of advice you're looking for?

[Jacquie Barker]

As I discuss in "Tip 8: Be Willing to Start at the Bottom," maintenance programming, while viewed as unglamorous drudgery by many, can be a great way to learn a new language or technology, as follows:

It gives you a legitimate reason to learn on the job -- after all, if you are debugging something that you aren't terribly familiar with, your management should be pleased to see you "crack a book" to learn about how it is supposed to work.

If you are fortunate enough to actually be debugging code that was well written (alas, not always the case), you will learn how to do it yourself on a go-forward basis -- this is how I learned to do GUI programming, way back in the days of X-Windows Motif on Unix! I'd never done GUI programming before, and was asked to embellish someone else's code, which gave me a leg up on understanding the GUI paradigm ... and, as I discuss elsewhere, understanding the paradigm has served me well time and again (e.g., when learning how to do Java Swing development several years later).

Then, there's the "brownie point" factor: if you are a team player who is willing to occasionally take on a less than glamorous assignment, hopefully your management will appreciate you for doing so, and will be willing to reward you with a project assignment that you are eager about the next time around.

As to Jeanne's comment:

Jeanne Boyarsky wrote:

Campbell Ritchie wrote:You should put your foot down and insist on being shown documentation.

And if there is no documentation to show you?

What you can do is make things better for the next guy. There may not be documentation now, but there's no reason there can't be in the future. Write down what you learn and start some documents. Get others to do the same.

I couldn't agree more! If no documentation exists for the code you are working on (unfortunately all too likely!), at a minimum, capture your insights in writing as you figure out the code you are supporting -- again, this may very well be perceived by management as "above and beyond the call of duty!"

[Akram Chotunukki]

Thank you Burk and Jacquie. You responses help me. You have answered on "why" part and to some extent "how" part of "art of debugging".

[Burk Hufnagel]

Akram,
You're very welcome. I hope it helps you.
Burk

[Jacquie Barker]

Ditto! Glad to have been of help.

Cheers,

Jacquie

[Jeanne Boyarsky]

Akrun,
I don't usually plug another book during someone's promo, but it's not a competing book so I don't feel bad. On January 12th, we are having a promo for Debug It! which covers just what this topic is about. The book is already on sale so you can buy it as an early Christmas present.