Another ten years or so passed, however, before I really learned how to debug software. That happened at my first job out of graduate school, when I went to work for a company that produced commercial software for computational fluid dynamics (CFD) analysis. The sort of scattershot debugging approach that I’d used up until then would no longer suffice. We had customers paying pretty hefty licensing fees to use our software, and when they reported a bug we needed to make sure that we could get a solid, reliable fix out to them so that their work wasn’t disrupted. It wasn’t enough to make the symptoms of the problem go away. We needed to understand what was broken, how it got that way, and only then implement a solution. Fortunately, one of my mentors at that company taught me this more rigorous approach to debugging software, one that I continue to use to this day.

Earlier this year, I had the opportunity to do a technical review of Paul Butcher‘s new book, Debug It! and now that it’s been published I’m pleased to be able to review the final product. A number of classic programming books, such as Steve Maguire’s Writing Solid Code or Steve McConnell’s Code Complete, touch on debugging as one aspect of the software development process, but I’m not sure that I’ve ever seen or read an entire book devoted to the topic of debugging software. In that regard, Paul’s new book fills a pretty interesting niche.

Paul breaks the debugging process up into four stages: reproduce, diagnose, fix and reflect. These stages are covered in detail in the first five chapters of the book, and this is the most important section. In the chapter on reproducing bugs, he touches on topics such as how to control the environmental conditions under which bugs manifests themselves, and techniques for reproducing the inputs that trigger the bugs. He also addresses some of the difficulties involved in dealing with especially difficult-to-reproduce nondeterministic bugs. In the chapter on diagnosis, Paul moves on to the process of forming a hypothesis about what’s causing the bug and then performing experiments to refine that hypothesis until you settle in on a root cause. There are a lot of useful guidelines here, including my favorite: Only change one thing at a time! The chapter on fixing bugs is relatively short, which reflects the reality that once you understand what’s going on it’s usually not that difficult to fix the problem. Here the author stresses the importance of adding regression tests, and making sure that you’re fixing the root cause and not merely the symptoms. The last step is to reflect on the significance of this bug and what it might be telling you about the overall quality of your code (e.g. are similar bugs lurking elsewhere in the code?)

The second section of the book (“The Bigger Picture”) takes a higher-level look at the issues surrounding software bugs, namely, how do you create an environment such that you stay on top of bugs and not fall into an “infinite defects” situation. It addresses topics such as tracking bugs and working with users and the support staff to better understand the bugs they’re seeing in production. The third section of the book (“Debug-Fu”) is sort of a hodge-podge of more advanced topics, I suppose. Some of the information in these later chapters is arguably out of place in this book. For example, Chapter 9, “The Ideal Debugging Environment,” stresses the importance of having automated tests, a continuous build system, and so forth. There’s no question that this is good advice; I’m just not sure that it’s completely on-topic for this book. Having said that, they are good disciplines for any programmer to have, and if the stuff in the rest of this book is new to you there’s a good chance that Paul’s advice on testing and continuous builds is new to you too.

It is important to note that the focus of this book is the debugging mindset, and strategies and techniques that you’ll use when debugging software. It does not teach you how to use any particular debugging tools. If you merely want to learn how to use the GNU debugger (gdb), or the graphical debugger in your IDE of choice, this is not the book for you.

In conclusion, I would highly recommend Debug It! to any junior-level programmer who’s interested in developing a more disciplined approach to debugging. If you’re not a junior-level programmer but still feel like you waste a lot of time debugging, you will probably find this book helpful as well. It’s like having a mentor sitting there with you, teaching you how to take your debugging game to the next level.

First, the obvious one. My goal (and my publisher’s “goal”, if you want to call it that) is to get the book finished. And we’re well on our way to accomplishing that.

Next, I want to learn a new programming language this year. Although I’m taking a look at Scala, I received Programming Erlang for Christmas (because my wife is just that good) and I’m liking what I’ve read about Erlang so far. I have the feeling that it’s going to win out. Scala reminds me a little too much of Java.

Lastly, I want to learn a lot more about developing applications for Mac OS X. That will no doubt involve my learning some Objective C along the way, but that’s not a bad thing. I’m especially eager to dig into the RubyCocoa framework that shipped with Leopard, to see how viable a platform that is for developing and shipping commercial Mac OS X applications.

What about you? What are some of the technologies that you think you’ll be checking out in 2008?

Be sure to watch the video (found at the bottom of the page) to see it in action. Oh, and don’t feel shame if it reminds you of Plinko — that’s the first thing that came to mind for me too.

Thanks to Seth Ladd for the link.

All of the projects that I work on use Subversion as their source control system, so I needed to find something that would play nice with it. SVK seemed like an obvious choice since it’s layered on top of Subversion, and there’s a port for it in MacPorts, so that’s where I started. After I got the software installed, I worked through Ron Bieber’s excellent tutorial series to get a feel for the SVK workflow. I highly recommend these tutorials if you’re considering using SVK.

I’ve been experimenting with SVK for a couple of days now, primarily doing some development on the FXRuby 1.6 branch, and it was working like a charm. I have to admit that it’s a little slow, especially considering that it’s just looking at stuff on the local disk. But it seemed to be working. Unfortunately, I just discovered that SVK doesn’t support the svn:externals property. That is, if a directory in your Subversion repository has the svn:externals property set on it, SVK will not properly mirror those external directories (it just ignores them). This isn’t an issue for the FXRuby repository, but many of the other projects that I work on make at least some use of Subversion externals. For the time being, that means no SVK for me.

So, back to the drawing board. I know of several alternatives that I can look at, like git, Mercurial, Bazaar and arch. The main requirement for me is that it works on Mac OS X, and that it plays nice with Subversion (i.e. it can both pull down the latest changes from a Subversion repository and push my changes back to that repository). And, um, it has to support svn:externals. Any suggestions?

Update: Looks like people are also talking about Monotone and darcs. Meanwhile, at first glance it doesn’t sound like git supports svn:externals either. I’m getting a sinking feeling that none of ‘em will. Oh well, we’ll see.

Given this reality, today’s news that Microsoft is demanding royalty payments, for what it claims are over 200 patent violations by a number of open source projects (including Linux and Open Office), should come as no surprise. Although it’s not quite the same circumstances, I can’t help but compare this to the embarrassing efforts by the SCO Group over the past four years to claim intellectual property rights to parts of the Linux kernel (while their plummeting stock price continually threatens to get them delisted by Nasdaq). As Charles Nutter put it, “I’d hate to be an OSS (Open Source Software) developer or apologist [working] at Microsoft today.”

1. Keep It DRY. The “Don’t Repeat Yourself” principle has wider application than the mere avoidance of code duplication. It’s also a mistake to duplicate knowledge about the intent or functionality of a method in the source code’s comments. As Mike notes, “If a comment already describes what the code does, then the comment is redundant and should be removed.” 
2. Make the Code Speak for Itself. That is, choose meaningful names for classes, methods and variables. If the purpose of a method isn’t fairly obvious from its name, there’s a good chance that it needs a new name. Invest the time and energy that you would have used writing a comment to “deodorize” that code smell, and use it to come up with a more descriptive name instead.
3. Write a Sweet-Smelling Comment. Use comments to tell why something was done: what purpose a class serves in the system, assumptions made by the code, and so so.