The Riddle of the Sphinx, Part One

The Sphinx is a mythical creature that delighted in posing seemingly unsolvable riddles. The riddle posed by the greatest Sphinx, the one at Giza, in Egypt, is surely one to which its architects knew the solution, and which I believe every truly successful software vendor must unravel. The riddle is, how does one build things to last?

 

Interestingly, exactly how long the great Sphinx at Giza has endured is still a matter of debate among Egyptologists. For many years, they generally believed that it was carved out around 2,500 B.C. However, another theory that emerged in 1979, pointed to evidence of erosion by water, signifying that the Sphinx is older than the desert itself, possibly dating back as far as 7,000 B.C. And a more recent, and complex hypothesis, based on, among other things, astronomy and a notion of what event in the sky the Sphinx was looking at, pushes the date of its construction further back, to 10,500 B.C. So, according to any plausible theory, the Great Sphinx has built to last a very long time.

 

Building things to last is a massive problem for software vendors. Usually, when software engineers discuss the minutiae of versioning, they are considering the problem of incrementally updating a computer program with bug fixes and small enhancements. Yet, software vendors face a much more severe problem in keeping their products up to date. The market expects them to periodically deliver whole collections of compelling new features. For Microsoft, as a platform software vendor, that entails that our operating systems, server products and development tools must evolve. The consequence of that, for our partner software vendors, is that the platform they depend upon is often changing, sometimes quite dramatically. And so we are confronted by the riddle of the Great Sphinx: how are we, together, supposed to compete in the market, frequently releasing new incarnations of our products, which involves shifts in the platform on which those products are built, and still preserve our investment in, and re-use pieces of what we have built already? How are we, that is to say, to build things that last when our foundation is never stable and when we are expected to always look brand new?

 

A question I often hear from Microsoft's partner software vendors is, “how should one migrate code written for Microsoft’s old platform to take advantage of the current platform?” They also ask how Microsoft’s platform is going to be changing.

 

I believe that in replying to those questions, I have a duty not just to talk about how to move this piece of legacy code forward to take advantage of that particular aspect of Microsoft’s platform as it is today, but rather to struggle with the bigger question of how to build software so as to anticipate its having to migrate it as your own product evolves and as Microsoft’s platform progresses—the question of how to build software to last, which is what I call the riddle of the Great Sphinx.

 

I'll offer some answers tomorrow.

Comments

• Anonymous
  June 14, 2004
  ddddddddddddddddd