Darwin and Intelligent (Software) Design
Is Microsoft software always the wisest choice to guarantee a project's survival?
- By Paul DeGroot
- July 01, 2006
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
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
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"
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
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
Here are some questions to help you handicap Microsoft's
- 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.
Paul DeGroot is principle consultant with Pica Communications, which provides consulting services for customers with complex Microsoft licensing issues.