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.

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.

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.

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.