Debug It! Book Review

One Minute Bottom Line

Have you ever had the luck to work with the kind of brilliant mind that is able to quickly see order in a messy code and even see what is wrong with it? Well I know a couple of guys fitting this description, and trust me I want to be able to do what they do. Although I will probably never reach that level I was expecting from this book to pick up some of the methods and techniques to get at least close to it. If you, like me, expect great things from this book maybe you should consider it. If you are a beginner and you've never worked in a big company with a structured software life cycle, maybe this is a good book for a start.

Review

The idea to write a book about debug is brilliant. There is an increasing demand for developers to fill positions where maintaining the code is an important part of the job. But we still don't have experts in this fields. We usually considered this part as a necessary task to perform and we prefered not to do it at all.

I think, as the author, that we should give more importance to debug and to all the techniques or best practices associated with it. As we do, for example, for the design and patterns. If you think about it all of us has at least a book about patterns. But how many of us have a book about debug?

I know designing a new software is a lot more fun than maintaining an existing one. But with the amount of code that is being written probably, sooner or later we will get a job where we need to do it.

So let's get to the point. The book is divided in three parts with "strange" titles:

1. The heart of the problem
2. The bigger picture
3. Debug-fu

The first part is very good, pages flow very quickly and there are really good points to keep in mind. The first one you will encounter is that debug is more than what we usually associate with this word. Debug is composed of these four phases: Reproduce, Diagnose, Fix and Reflect. I'm sure that just by mentioning them you already have an idea about what they are but I want to mention a couple of them.

Reproduce a problem is in the first thing to do. We often skip this important step because we think to know where a problem is especially if we worked on the software we are checking. Nothing is more wrong than that and should always be avoided. You should always try to verify your idea. Better if with a unit test.

Another very good point in the first part of the book is the empirical technique. It is explained in the "Diagnose" chapter (you can even find the free chapter here http://pragprog.com/titles/pbdp/debug-it). It goes like this.

If you have a bug you can follow these steps :

1. construct an hypothesis with what you know
2. design an experiment to prove the hypothesis
3. if the experiment fail go back to point 1
4. if the experiment supports your hypothesis keep trying to find new experiments until you are certain that you have a complete view of the problem

Usually while I'm reading a book I stick cards to the pages containing important concepts. Now that I have finished to read the book I can see that 90% of the cards are in the first part while the rest of the book doesn't have much. Maybe is just because I already knew the concepts but... you get the point.

You will find all sort of things in the rest of the book. All the stuff we are used to in our daily life as developers ranging from the use of version system for the code to a strict delivery process.

So even though I'm disappointed by the shortage of arguments in the book, you will not waste time in reading it. At least at the end of it you will have clear in mind that debug is not just the act to find a bug but is a process to maintain the software. Another good thing about this book is that it is really nice to read. You can read it even on Monday morning on the tube to get to work without falling asleep.