Author Archives: G Wade Johnson

Review of Perl Best Practices

Perl Best Practices Damian Conway O’Reilly, 2005 This book is hard to summarize. There is much good advice in this book. Unfortunately, there’s also some advice that I found questionable. Conway covers some of important Perl programming and general programming best practices, including consistent formatting, use of strict and warnings, and the use of version… Read More »

Accuracy and Precision

When I was getting my EE degree many years ago, one of my professors (Dr. Dave) had an interesting lecture on the difference between accuracy and precision. Even though many people use these terms interchangeably, they are separate concepts. Possibly the most important point of separating these two concepts is remembering that they may be… Read More »

Review of Waltzing with Bears

Waltzing with Bears Tom DeMarco & Timothy Lister Dorset House Publishing, 2003 The authors of Peopleware are back to tackle the topic of risk management. Given their earlier works, you would expect DeMarco and Lister to provide good insights into the topic and clear explanations. In that, you will not be disappointed with this book.… Read More »

Diff Debugging

Every now and then, I manage to pull myself away from reading and reviewing computer books (my hobby for the last year) or programming (my hobby for … never mind), and spend a little time on various weblogs. It’s important to see what the names in the field are thinking and talking about. During one… Read More »

The IP Goose

One of the problems with being a software developer these days is company Intellectual Property agreements. I understand that companies want to protect the time, money, and expertise that they have invested. But some of the agreements I have seen go way past reasonable concern. Some IP agreements take the position that any programming a… Read More »

Maintenance Programmer vs. Original Programmer

In the book Software Exorcism, Bill Blunden described a problem caused by the maintenance programmer not usually being the same person as the programmer who wrote the code. Often the maintenance programmer comes in with a less-than-complete understanding of the original problem or of the design decisions made for this problem. Usually, there are also… Read More »