I've now been working in the computer field for 36 years -- longer than the majority of today's IT professionals have been alive -- and, for all practical purposes, Moore's Law has prevailed for my entire career. Every 18 months, according to the legendary hardware guru Gordon Moore, the processing power of a microchip doubles.

The traditional approach to project management recognizes that project objectives can change over time -- they are dynamic throughout the life of a project and are supposed to be changed as part of management control. However, two problems still persist in this area: (1) coping with radical changes, and (2) measuring success.

Software theorists have been talking about developing new software applications with reusable components for a long time. The idea is obvious: why develop new code when you can simply snap together already available components that provide the needed functionality. An analogy is usually made, claiming that the amazing successes of computer hardware depend on the existence of standards and hardware components.

In the October issue of the Cutter IT Journal, I wrote about the fact that " You Don't Always Get What You Want: But You Do Usually Get What You Ask For." As an addendum to that, here's another thought: if you don't know what you want (or don't make it clear), you probably won't get it!

I recently conducted an e-business visioning session with the executive management team of a company in the financial industry. The inspiration for the meeting was the CEO's concern over whether an e-business project proposed by the company's IT department was aligned with the strategic business opportunities offered by the Internet. At first blush, the IT proposal seemed incremental.

Ever since XML was introduced, people have been talking about the possibility that it could be used as a kind of Internet middleware. Skeptics have pointed out that XML is a document format. It isn't middleware -- it lacks any of the services traditionally associated with middleware, including the ability to locate distributed components, transactions, security, and so forth.

People who design or code something shouldn't test it. The classic reason is they may not see problems that others can. I've recently stumbled onto another reason, and that reason can save projects time and money.

Many years ago I remember someone explaining to me that the reason the Roman Colosseum was still (more or less) standing was due to the fact that the people who tried to tear it down and use it for a stone quarry in the Middle Ages were less skilled than the engineers who built it originally.

This is the fourth Advisor in my series on risk management.

Enterprise application integration (EAI) continues to haunt the thinking of those who are tasked with designing large e-business applications.

Some of you have probably heard of Extreme Programming, or XP, as it is usually called. XP is a lightweight software development methodology that advocates (Kent Beck, Ron Jeffries, and others) claim is a way of developing high-quality software with low schedule and budget risk.

A colleague of mine tells a funny story about interviewing for a job with Sun Microsystems when she was nearing completion of her MBA at Stanford University, California, USA. It was the mid-1980s. Sun was an exciting young company operating in the shadow of larger rivals such as Apollo and Computervision (remember them?).

I've been playing around with an idea for several months in conjunction with a new book I am working on. In effect, I thought about extending the popular "patterns" approach to provide a way to help business managers think about the kinds of changes they could make in their organizations. A lot of companies are thinking about transitioning to e-business models.