Silver bullets and wooden stakes are time-tested components for dealing with vampires and werewolves. Of course, you have to remember which component is to be applied to which monster. Unfortunately, you also have to be at pretty close range to use these components. Use the wrong one, and you are unlikely to have a second chance.

Although the marketplace seems to be fascinated with the UML-RUP (Unified Modeling Language-Rational Unified Process) approach to object-oriented development, I believe that there are many reasons why UML-RUP is insufficient for component-based development. UML-RUP seems suited for "green field" projects. It provides no help in dealing with the development or with the reuse of components and designs.

At a recent conference, I had an interesting discussion with a manager about iterative development practices. As we discussed the advantages/disadvantages of the approach, he summarized his position as follows. "You know, I don't really see anything different in this new, iterative style of development. We've always iterated. Still do. We start with a simple entity-relationship diagram and refine it through successive meetings until we get it right. Then we move to design and continually refine our design until it is right.

The recent barrage of articles in the information technology press regarding enterprise information portals are heralding several converging trends:

When Copernicus initially proposed that the earth revolved around the sun, his theory was met with derision. After all, any damn fool could look up and see that the opposite was true. A century and a half later, after proving that Copernicus was right after all, Galileo was packed off to Rome to have a little chat with the Inquisition.

I found myself trying to explain a meta architecture to a colleague the other day and came up with the following rather belabored analogy.

Many software organizations are asking themselves, "What should we do to get better?" Some companies attempt to answer this important question by embarking on a thorough (and expensive) benchmarking study. "By comparing ourselves against the best software organizations, we will find out exactly what to try to become even better," is their logic.

I recently spent almost half a day in a room with about 15 senior project managers who were reporting their project status to the CIO of the company. I listened patiently as each one went through their reports and PowerPoint presentations.