For computer scientists, software engineers, and almost anyone else who works in the IT industry, talking about artificial intelligence (AI) is roughly akin to talking about religion or politics: everyone seems to have a very strong opinion and they tend to articulate those opinions in loud, strident voices.

One of the consequences of the dot-bomb explosion is confusion about what to do about e-business. Is e-business a flash in the pan? Where will e-business go from here? How can we use e-business in our company? Should we? These questions, and more, weigh heavily in many current business and IT strategy-planning efforts.

I'm impressed with the way IT people are thinking in broader and more businesslike terms than in the past. I attribute this to the rise of e-business and the success of enterprise resource planning (ERP) applications, among other things.

The recent slowdown of the dot-com area has given many people plenty of time to reconsider software practices and principles. What went wrong? What could we have done differently? How did so many smart people fall into something that wasn't going to work?

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.