Debuggers are a wasteful Timesink
Bob Martin writes, "As debuggers have grown in power and capability, they have become more and more harmful to the process of software development."
We lead off Also in Java Today with a link to Uncle Bob's Artima.com weblog entry Debuggers are a wasteful Timesink. It struck a nerve because I had just sent out an email to someone to the effect that I haven't used a debugger in the last two years when I read John Mitchell's entry linking to this thread.
I said goodbye to the debugger shortly after driving to Chicago to spend a week in an XP Immersion run by Bob Martin and Ron Jeffries and others. I've never liked the debugger but always worked with people who swore by it. They happily stepped in and out of methods and checked values of variables and nodded their heads knowingly. Some used the tool to quickly locate problems and others seemed to gather tons of information but no insight.
Bob writes that "The kinds of bugs I have to troubleshoot are easily isolated by my unit tests, and can be quickly found through inspection and a few judiciously placed print statements." He warns that there are programmers who stop depending on their own insight and instincts and instead blindly depend on a debugger. He argues that "a debugger is a tool of last resort. Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just rewriting the offending code, *then* you may need a debugger."
One response to Bob's post is that a debugger is a useful tool when trying to navigate and find the source of problems in someone else's code. This includes a pointer to our other linked article today. The ACM Queue article by George V. Neville-Neil Code Spelunking: Exploring Cavernous Code Bases. Neville-Neil writes "Code spelunking is very different from other engineering practices because it is done long after the initial design and implementation of a system. It is a set of forensic techniques used after the crime has been committed."
In particular, the article points to the problem of "attempting to fix a bug in an unfamiliar piece of code. Debugging is a highly focused task: You have a program, it runs, but not correctly. You must find out why it does this, where it does this, and then repair it. What's wrong with the program is usually your only known quantity. Finding the needle buried in the haystack is your job, so the first question must be, 'Where does the program make a mistake?'"
The article points to mistakes that are best handled by a debugger and those that aren't. For example locating a problem "where the code doesn't crash but only produces incorrect results, is more difficult because there isn't a trivial way to get a debugger to show you when to stop the program and inspect it. "
It is interesting to return to the forum and follow the thread that Uncle Bob started. He is suggesting that perhaps the debugger is overused and that there might be a benefit in taking a step back and noticing which tools you reach for and questioning when and why.
In Weblogs , Jack Shirazi announces the November Java Performance News. I look forward to his monthly announcements and usually feature an article or two in the Also Today section over the next couple of weeks. He writes that someone "told me that they think my announcements of my newsletters are not appropriate for a blog."
I have two basic rules for the java.net bloggers (other than treating others with kindness, respect, and so on). Their entries should be of interest to Java developers (though not necessarily on Java specific topics) and no marketing. You could interpret Jack's email as marketing. On the other hand, the bloggers frequently link to articles they found interesting or that they wrote that they hope you will find interesting. I've always looked at Jack's monthly post as an itemized link to articles you may find interesting.
John Mitchell builds on a comment from Sue Spielman's Practical JSTL article. In The "Community" is Always Right? John emphasizes a passage from Sue's article in which she argues why you do not want to be able to perform SQL actions in your JSP pages. Sue writes that even though there are many reasons not to do so and that many members of the expert group agree with her - this functionality is in the final draft because "The community has asked for it, the community has gotten it."
This drove John to his keyboard where he notes that this is another example of the type of "mushed together 'solutions'" that keep many consultants employed fixing "out of control" systems. Join in the discussion of whether a popular vote is a proper way to get a "best solution".
Alan Williamson notes that We have Applets, Servlets and MIDlets, we now need CARlets. With Microsoft's announcement that "hey want