Blog

Sometime I hate to admit how long I have been writing code - it tends to give away my age. The first program I wrote was in Apple Basic on the brand new Apple IIc (insert joke about my age here). But coding for as long as I have been has given me an interesting prospective on the tools and methodologies we use to develop software. The occasional look back to the ways we used to code makes you appreciate the current practices that much more.

Today I revisit the arduous task of debugging…

Whether developing an application from scratch, or working on support, every developer will at some point need to debug the code.  Now for my casual non-developer readers (translate: not as big of a nerd as I am), debugging is the process of taking a snapshot of the application’s state at some point in the execution of the code.  With modern Integrated Development Environments (IDEs) like IntelliJ or Visual Studio, this is fairly easy to do.  Insert a break point anywhere in the code with a click of the mouse, and when the application runs it will pause on that line and not continue until you tell it to.  During this paused state, a developer can look at all of the variables and fields and their values, and even run secondary code fragments based on the current state.  Basically, you are looking at the code and data as the application sees it at that particular point in time.  Sound useful?  You bet it is.  But IDE integrated debugging is only a recent entry into the fray.  Prior to that, we had to do it (gasp) manually.

Here is an example of some old school debugging in Java.  Take the following code snippet:

    public int compareTo(Object o) {
        User oUser = (User) o);
        if (this.getLastName().equalsIgnoreCase(oUser.getLastName())) {
            return this.getFirstName().compareTo(oUser.getFirstName());
        } else {
            return this.getLastName().compareTo(oUser.getLastName());
        }
    }


This is a fairly easy compareTo method that orders a User object by Last Name then First Name.  But what if it wasn’t working for some reason?  We would need to insert some kind of debugging to figure out why it wasn’t working.

    public int compareTo(Object o) {
        User oUser = (User) o);
        System.out.println("*** Debug: this = "
            + this.getLastName() + ", " + this.getFirstName());
        System.out.println("*** Debug: oUser = "
            + oUser.getLastName() + ", " + oUser.getFirstName());
        System.out.println("*** Debug: Last Name compare= "
            + this.getLastName().compareTo(oUser.getLastName()));
        System.out.println("*** Debug: First Name compare= "
            + this.getFirstName().compareTo(oUser.getFirstName()));
        if (this.getLastName().equalsIgnoreCase(oUser.getLastName())) {
            return this.getFirstName().compareTo(oUser.getFirstName());
        } else {
            return this.getLastName().compareTo(oUser.getLastName());
        }
    }


OK, this probably gives enough information to figure out what the problem is.  Unfortunately it also gives you a lot of information you DON’T need.  What if you were sorting a collection of 100 user objects?  We all know from our computer sciences back in college that the best we can expect out of a sorting algorithm is to complete the sort in n * log(n) operations.  That means in a collection of 100 user objects, the compareTo method is called 200 times.  So we have 4 lines of debugging info X 200 operations being sent to the console.  That means up to 800 lines of output that the developer needs to wade through to find his or her error.  Have fun with that.  Yeah, we can get more creative by including if-else statements, or try-catch blocks to limit the number of statements, yadda yadda yadda.  But now we are writing code to debug code.  What happens if there is a flaw in the debug code logic.  How do we debug that.  And what happens if the execution error happens in another method or object?  In the code above, we could go through all that work to determine that it is the compareTo method of the names that is the problem, not on the User object itself.  You get the picture.  Debugging applications, even 10 years ago, was a pain.

So the next time you are complaining about having to step through twenty or so lines of code to find an error, think about how much more work could be involved and be happy that you are fortunate enough to be developing with modern tools.

(On a side note, back when I was in college, we walked to class uphill both ways, without shoes, in the winter…)