Preface

Why I Wrote This Book

When I first learned to program, I found the process of testing and debugging very frustrating. I can remember slamming my fist down on the hard metal shell of the Selectric typewriters we used to interact with the timesharing system at the amazing speed of 15 characters per second. The bugs didn't disappear any more quickly for the beating. None of my professors taught me anything about testing and debugging that I can remember.

During the nearly 30 years that I have worked in software development, many aspects of the profession have changed. Languages have become popular and gone out of favor. Better development methodologies have been introduced, only to be replaced by yet more sophisticated methodologies. Microprocessors have become ubiquitous, and software has become the driving force behind many new products. The laptop computer that I wrote this book on has a faster processor, more memory, and more disk space than the multimillion dollar IBM(tm) mainframe on which I learned to program.

Some things have not changed, however. Software products still contain far too many bugs. Software developers still spend far too much time finding and fixing those bugs. People who are learning to program spend far too much time struggling to learn by trial and error.

I wrote this book because I wanted to introduce a systematic approach to debugging to a wide audience. If you learn something from this book that enables you to find and fix bugs more quickly, then I will have succeeded.

Who Should Read This Book

This book was written with both students and professional programmers in mind. Any student who has completed a course in computer programming and a course in data structures and algorithms should be able to understand and apply the material in this book. Professional programmers should find new ideas to make them more productive, along with new twists on old ideas they have been using for years.

The case studies were done in C++ and Java because they were the most popular programming languages in use when this book was written. I refer to other popular languages, particularly C and Fortran, when they are relevant to a particular topic. Since this book focuses on how to think about debugging, rather than on specific platforms, almost all of the material is relevant to all programming languages. If your primary language is not Java or C++, you should still be able to apply at least 90 percent of the material in this book.

How to Read This Book

There are several reasons that this book takes a multidisciplinary approach to debugging. One reason is that people are unique, and different people have different preferred modes of learning. Some people need to see things to learn, others prefer to hear new material, and others have trouble understanding unless they can work something with their hands. In a similar way, some people will relate to some of the lessons of certain disciplines better than others.

When the material in this book was presented in classes for computer science graduate students, I found a wide difference in which disciplines the students found most interesting or helpful. Some absolutely loved the analogy to detective literature. Others were uninterested. Some were fascinated by the study of human error. Others had trouble seeing how it was relevant to them. If you have problems relating to the analogy of one particular discipline, move on to another one, and come back later to the first one.

An undergraduate student who wants to develop debugging skills quickly should probably read chapters 1-4, 7-9, 5, 10, 11, and 15, in that order. Graduate students in computer science should add chapters 12-14 after that.

A professional programmer with years of experience may not feel the need to read the case studies (chapters 5 and 10). If you aren't sure whether a chapter will be of use to you, read the review at the end of the chapter first.

The material in chapters 6 and 12 is more theoretical than the rest of the book. Chapter 6 gives the rationale for the organization of chapters 7-9.

Chapter 12 applies ideas from cognitive psychology that attempt to explain how programmers create bugs.

Make sure that you read chapter 15, and make a plan for applying what you have read.

Typographical and Grammatical Conventions

Italics are used to emphasize a point and identify the names of publications and products.

Boldface is used to introduce new terms, which are collected in the glossary, and to distinguish programming language keywords and commands from the text.

Example material that is computer generated, such as command-line entries and source code listings, is set in the following typeface: 

This is a computer listing

Example material that isn't computer-generated, such as algorithm descriptions and debugging logs, is set in the following typeface. 

This is a debugging log

Choosing the right third-person singular pronoun is a difficult task these days. In this book, unknown software developers are referred to as "he or she."

Acknowledgements

Thanks to my wife Marcia for encouraging me to finish a book I had been talking about for 10 years. She suggested that I read the Lord Peter Wimsey mysteries, and the result is apparent in this book.

Thanks to Dr. Lawrence Rauchwerger, Dr. Nancy Amato, and their graduate students at Texas A&M University for giving me opportunities to present an early version of this material to them and for giving me valuable feedback on their classes.

Thanks to my managers at Hewlett-Packard, Betty van Houten, Steve Rowan, and Ty Rabe, who gave their permission for HP Press to publish this book.