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.

I'll admit it: I'm one of those people who has made an occasional disparaging remark about COBOL. It's such an easy target, it could almost be the subject of a skit on Saturday Night Live if the actors knew anything about programming languages.

Many firms are having serious doubts about IT's ability to deliver business intelligence (BI) systems. After participating in many BI strategy and implementation efforts, it has become apparent that neither the IT function nor the business users have the mindset to deploy and utilize BI systems correctly. Corporations today are drowning in terabytes of transactional data.

Over the past 12 months, I have been teaching a series of public object technology courses across the US. To my continuing surprise, most of the participants were from sophisticated organizations that I would have believed had undertaken and completed the migration to object technology years ago.

A headline in a recent issue of Internet Week caught my attention.

When most of us think of the Object Management Group (OMG), we think of an 800-member standards body that defines abstract specifications for middleware architectures like CORBA and its recently announced Model Driven Architecture. It certainly does those things, but it also provides a meeting ground for many industry and domain groups that are developing their own frameworks and standards.

Traditional project management was driven by technically oriented project managers who worked in the traditional hierarchical culture of the broader organization.