Directions

Darwin and Intelligent (Software) Design

Is Microsoft software always the wisest choice to guarantee a project's survival?

Sometimes the question isn't "Should I use Microsoft for my project?" but "Which Microsoft technology should I use?"

Take a collaboration scenario that uses instant messaging. You have your basic Windows Messenger that ships with Windows XP. Then there's MSN Messenger, Office Communicator, Windows Live Messenger, Live Communications Server, Communicator Mobile, Exchange Instant Messaging, Exchange Conferencing Server, Live Meeting, the Windows Communication Foundation and Windows MeetingSpace.

No two technologies are identical. Some are embryonic, others are gasping for air. Some are for business, some for consumers. Some come from the Windows team, some from Office. And at some point, Microsoft trumpeted each as an innovation that would "Change Life on Earth." So how do you choose? After all, backing or buying the wrong one will be an expensive mistake.

Microsoft is in the unusual position of having so much money that it can fund multiple competitive technologies without worrying that only one is likely to succeed. Partners who bet on the right technology can win big. Those who don't wind up as fossils.

At Directions, we call this the "Darwinian" approach to software development: Try solving a problem or capturing a market opportunity in a bunch of ways and see which one lives the longest. Internally, Directions on Microsoft sometimes rates Microsoft technologies by the number of "Darwins" they get.

For example, Office developers can choose from a host of overlapping and competing technologies. We gave one of those technologies two (out of a possible five) Darwins when it came out, and bumped it up to three when a major Microsoft partner used it for an integration project. Alas, that team's next project didn't use the technology, so it's dropped to 1.5 Darwins.

The Darwinian approach has certainly paid off for Microsoft, but it's far from perfect. Microsoft may have three times as many employees working on a problem as are really needed to solve it, and fine people often work overtime on projects that never reach fruition. Both circumstances have human and financial consequences, even for Microsoft. Meanwhile, customers grow disillusioned when promising and highly anticipated technologies languish in beta or never successfully jump from a Microsoft white paper to code. And when too many competing versions of a technology exist, some customers will delay spending until Microsoft sorts out which technology to promote.

Pick a Winner

Here are some questions to help you handicap Microsoft's emerging technologies:

  • Did the product come from a strong team with a prominent leader? (Bonus points if the leader is a friend of Bill Gates or Steve Ballmer.)
  • Does Microsoft use the product or technology itself?
  • Does the pr oduct help Microsoft compete?
  • Do Microsoft development tools support it?
  • Can it be managed with Microsoft's management tools?

As a partner, you must often pick a winner even further in advance than customers. Your personal notion of optimal product quality isn't enough. You'll fare better if you rely on a team with a prominent leader or champion. There are other considerations as well. A product optimal for a small market might spark little interest in Microsoft's enterprise sales force. A strong competitor might cause Microsoft to anoint the comparable Microsoft project closest to completion as the company's standard bearer, even if it's not the best.

Ideally, you'll get in early to take advantage of the high prices that hot technologies command, train exactly the right number of people and receive solid marketing from Microsoft. But if you back the wrong choice, you could find yourself doing CPR on a fish with a fur tail.

About the Author

Paul DeGroot is principle consultant with Pica Communications, which provides consulting services for customers with complex Microsoft licensing issues.

Featured