News

Preventing programming errors: An interview with Brian Hawkins

• By Dan Romanchik
• April 29, 2003

Brian Hawkins is the author of "Preventative Programming Techniques: Avoid and Correct Common Mistakes" (Charles River Media, 2003). The book identifies the most common ways programmers make mistakes and how to avoid and correct them. Programmers Report recently asked Hawkins a few questions about this topic.

Q. You identify three major illnesses afflicting programming -- premature optimization, the cut-and-paste endemic and the not-invented-here syndrome. Which of these is the worst, and how can programmers and companies avoid it?

A. It is hard to choose one of these as the worst because they are all very common and destructive problems. If I had to choose, I would probably say not-invented-here syndrome is the worst. This behavior will only become more problematic as the software industry advances. Those companies unwilling to build on what others have done will find themselves less and less able to compete because others will be faster to market with more full-featured products.

The simple answer for avoiding this is to encourage the use of external libraries and code. Of course there are a number of issues that can arise when attempting this, and a certain amount of caution is necessary. Management and programmers can become discouraged if they take the wrong approach to adopting third-party libraries.

Q. Aren't many of the mistakes you describe in the book process problems? By that I mean, couldn't many of them be avoided if there were more code reviews and testing, or if perhaps companies adopted Extreme Programming techniques?

A. Unfortunately, a process is only as good as those implementing it. Also, the more process that is imposed, the more development time is lost to that process. If you can employ disciplined programmers that avoid these problems without unnecessary process overhead, then you will be one step ahead. In fact, this is much of what Extreme Programming is about. Small, disciplined teams with minimal process can accomplish the same thing as large teams of mediocre programmers with strict process.

As for code reviews and testing, I strongly advocate these in my book. However, both catch problems after the fact and are not as effective as preventing the problems to begin with.

Q. Are there any tools available that programmers can use to detect some of the problems described in your book? For example, are there any code analysis tools that may warn a programmer that his or her code is overly complex?

A. Parasoft makes several code analysis tools, such as CodeWizard, to help detect problematic coding. Rational Software also provides tools for code analysis. These can assist a programmer, but are not full solutions. It is still important for the programmer to use discipline and careful thinking when writing code.

Q. Aside from reading your book, what advice would you give to recent graduates who want to become good programmers?

A. Keep learning. Find a knowledgeable mentor and continue to read and attend conferences. Programming is a fast-moving field and you must keep an open mind to remain on top. Finally, be prepared to do work that you do not always enjoy. You will have plenty of tasks that are fun, but it is still important and necessary to do those that are not.

To link to the "Preventative Programming Techniques: Avoid and Correct Common Mistakes" Web site, including sample chapters, please go to http://www.charlesriver.com/titles/preventativeprog.html

Links:

For other Programmers Report articles, please go to http://www.adtmag.com/article.asp?id=6265