wood burning stoves 2.0*
The moose likes Jobs Discussion and the fly likes Improving Debugging Skills Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "Improving Debugging Skills" Watch "Improving Debugging Skills" New topic
Author

Improving Debugging Skills

Akram Chotunukki
Greenhorn

Joined: Nov 16, 2009
Posts: 3
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
Author
Ranch Hand

Joined: May 31, 2007
Posts: 3219
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.


Java Interview Questions and Answers Blog | Amazon.com profile | Java Interview Books
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38044
    
  22
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
internet detective
Marshal

Joined: May 26, 2003
Posts: 30130
    
150

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38044
    
  22
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
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Akram Chotunukki
Greenhorn

Joined: Nov 16, 2009
Posts: 3
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
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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
author
Ranch Hand

Joined: Dec 20, 2000
Posts: 201


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!"



    Author of Beginning Java Objects, Beginning C# Objects, and Taming the Technology Tidal Wave
    Akram Chotunukki
    Greenhorn

    Joined: Nov 16, 2009
    Posts: 3
    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
    Ranch Hand

    Joined: Oct 01, 2001
    Posts: 814
        
        3
    Akram,
    You're very welcome. I hope it helps you.
    Burk
    Jacquie Barker
    author
    Ranch Hand

    Joined: Dec 20, 2000
    Posts: 201
    Ditto! Glad to have been of help.

    Cheers,

    Jacquie
    Jeanne Boyarsky
    internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30130
        
    150

    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.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Improving Debugging Skills
     
    Similar Threads
    Advice needed -- sysadmin to enterprise developer career transition
    tools and complexity of debugging
    Java/SOA System Engineer, Confidential, Pomona, NJ
    Thanks JavaRanchers
    Calling Project Managers for US 3rd largest ISP based at Hyderabad - India !!!