Automated software test tools have a high disappointment rate. After an initial flush of excitement of recording test scripts, the tool often becomes "shelfware," and testing returns to the old manual methods. The keys to successfully implementing an automated test tool are preparation, training, and realistic expectations. Here are answers for some of the common pitfalls and misconceptions.

Simplicity should be simple -- shouldn't it? Unfortunately, simplicity isn't always simple, and sometimes it's down right difficult.

I attended a lot of interesting sessions at Sun's Java One conference last week. The two that impressed me the most were on reuse. Reuse has been one of those topics that has been strongly associated with objects and component-based development for well over a decade, so it's useful, once in a while, to do a reality check.

One of the biggest challenges that agile development methods face is developers claiming to be following the method -- when in reality they aren't -- who then run into trouble and proceed to blame the method they weren't following properly to begin with. We're seeing this in the case of extreme programming (XP), where hackers choose to follow a subset of XP's practices, yet claim to be following all of XP's tenets.

The final leg of my European journey was to attend and speak at the Extreme Programming and Flexible Process 2001 conference near Cagliari, Sardinia, Italy.