This is a guest post by Justin James, the host of TechRepublic’s Programming and Development blog.

Microsoft is in deep, deep trouble with Windows Phone 7, and it is the company’s fault. After the initial surge in interest amongst developers when Microsoft first showed off the platform, the company has consistently failed to engage and motivate the development community, and it will pay a heavy price when they struggle to get this thing moving.

Let’s look past the business challenges (such as wasting so much time that iOS and Android took over the marketplace) and the technical shortcomings of Windows Phone 7 (no removable storage, no tethering, no CDMA until 2011) because those points are well covered elsewhere. Instead, we need to look at how Microsoft has done a slipshod job at motivating developers to look at this new platform.

Microsoft has chosen a consumer-centric strategy, which is heavily dependent on having applications. Some of the best advertising for a mobile platform is when people are in the same room, and one person shows off their shiny new toy, and their favorite apps are part of that ad-hoc demo. (That silly Paper Toss game on the iPhone probably moved as many units as any Apple television ad.) Even if Microsoft was focused on the enterprise, there would still be big issues there too; as I’ve written previously on TechRepublic, the story for enterprise developers is not what it needs to be.

Mobile development survey results

Appcelerator has started conducting quarterly surveys of mobile developers. I like reading the results because the surveys tap a group of people who are really on the cutting edge, and they give a good idea of where things are going. Appcelerator’s Q3 2010 survey results were recently released, and they are absolutely fascinating. According to the report, a mere 28% of mobile developers are very interested in developing for Windows Phone 7. This doesn’t sound so bad, until you consider that 62% are just as interested in developing for Android tablets (another device on the edge of launch), and 34% are just as interested in developing for BlackBerry phones (a market that seems to have a limited long-term future).

The ultimate insult to Windows Phone 7 is that the developers who said they were very interested in developing for the iPad was nearly 60% in January 2010, months before the device was on the market. Twice as many people were very interested in developing for a device that little was known about more than for a platform that had public tools for months, plenty of press, lots of evangelism, and more. The only mobile platform with less interest than Windows Phone 7 right now is WebOS, which is effectively dead for the moment, since it has been bought by a company (HP) that doesn’t make phones (at least not yet).

Windows Phone 7 apps

Emblematic of the problem is the CNET gallery of “cool” Windows Phone 7 apps; not only are the apps boring (restaurant recommendations are so 2008), but from what I can tell, the cookie-cutter, me-to apps do not take advantage of the platform. And to make things worse, I count only five apps in the lineup. If Windows Phone 7 is such a development hotbed, why could only dig up five applications worth discussing, one of them being the Twitter application? (More Windows Phone 7 apps galleries: 3 music apps for Windows Phone 7 and A look at some Windows Phone 7 apps.)

Windows Phone 7 app from Motolingo

Where did Microsoft go wrong?

As someone who has been very excited about Windows Phone 7 until the last month or two, I’ve observed that Microsoft has made these four major mistakes:

  1. Microsoft has based the development on Silverlight.
  2. The development tools have been tardy and lacking.
  3. Microsoft has done an uncharacteristically lousy job at engaging anyone other than “the base” (to borrow a phrase from politics).
  4. Microsoft has not proven that it can deliver enough customers to motivate developers to spend time learning the platform. (Do you plan to purchase a Windows Phone 7 device? Take the TechRepublic poll.)

Let’s go through each of these points one by one.


Silverlight is a cool platform; unfortunately, Silverlight’s adoption rate among developers is still rather low. While Silverlight development is quite visible, and there seems to be a ton of demand for experienced Silverlight developers, there are not many of them and for good reason. Silverlight has had too many revisions in too short a period of time. For the most part, only developers who are truly passionate about Silverlight have the time and the emotional wherewithal to keep their skillset up-to-date, let alone invest in it in the first place. To make matters worse, too many Silverlight articles are hung up on the kind of pedantic details that drive most “in the trenches” developers insane; for instance, drawn out discussions around the MVVM pattern (which no one explains well and few people truly understand).

The biggest problem with Silverlight is that the stack is just too deep. Silverlight by itself can’t do a lot of things; you need to know a pile of service-side technologies to get anything out of it. Want to access a database? You need WCF Data Services. If you want parallel processing, you’ll need to do it as a Web service. The list of things that Silverlight (or Silverlight on Windows Phone 7) can’t do on its own is staggering, forcing you to engage all sorts of server-side technologies.

The display model (WPF) is unfamiliar to most .NET developers, who are either using ASP.NET or WinForms. Getting the best use out of WPF requires that you learn Expression Blend (which is no small feat), or you work with someone who knows it well (and those developers cost a pretty penny to hire).

Silverlight is not a bad technology, but anyone considering Windows Phone 7 development who does not already know Silverlight will have to tackle a daunting mountain of books, videos, and tutorials on the subject. I’m not the only one who feels this way, either; according to a recent TechRepublic poll (at the time of this writing), about 60% of readers think that Silverlight is too complex.

Development tools

The Windows Phone 7 development tools came out of beta several weeks ago, and the Windows Phone 7 launch occurred today — that’s not a lot of time if you were waiting for the tools to be final to get working. More importantly, the emulator that shipped with the tools seems to be fairly useless. I’ve read too many comments from developers saying that they simply cannot test their application without a test handset; unfortunately, test handsets have been limited to very few people. If Microsoft wants to prevent people from developing for their platform, forcing developers to buy a handset (possibly one they can’t even use, thanks to the lack of CDMA support until next year) before they can test many common features is a great way to do it.

Community engagement

Microsoft’s engagement with the developer community is usually quite good, but that is not the case with Windows Phone 7. For the most part, the only people talking about Windows Phone 7 development are Microsoft employees and MVPs, and it’s because Microsoft has been so lackluster at reaching out.

For instance, I contacted my Microsoft PR contacts asking for details on Windows Phone 7 and preferably a demo handset to work with, and I got nothing useful; I felt a little better about my response when I found out that Dr. Dobbs could not procure a Windows Phone 7 handset either. However, CNET’s Ina Fried and ZDNet blogger Mark Miller, neither of whom are developers, have had demo units to write stories about their experiences using it, even though the demo units were supposedly for developers only. I’m not knocking Ina Fried or Mark Miller — both have great reach, and they should have a demo unit — but don’t tell me that the demo units are only for developers, give demos to non-development press, and deny one to me or Dr. Dobbs. If you want to alienate the potentially favorable press, that’s a great way to do it!

I haven’t had much luck getting information through other avenues either. At my local user group, an MVP gave a good presentation about the platform, but there was no real hands-on interaction. I got in touch with my local developer evangelist to get Windows Phone 7 development details, and he referred me to someone else who never called me back. My local user group can’t seem to get anyone from Microsoft to do a presentation on the topic. It wasn’t until mid-September that Microsoft sent folks around to do the Firestarter events, and they were typically limited to a mere 50 people (I signed up, but I could not attend due to work getting very busy that week). And outside of the developer evangelists and MVPs, there really are no blogs or articles being written on a consistent basis about Windows Phone 7 development. Jeff Blankenburg, a Microsoft Developer Evangelist, is the only person I’ve seen one who writes to an audience other than the hardcore Silverlight development crowd.

In the past, Microsoft saturated even the relative backwater of Columbia, SC (where I live) with presentations about ASP.NET MVC, WCF Data Services, Azure, and Parallel Extensions Library from developer evangelists and such. Getting information was easy, and CTPs were available long in advance and were quite complete. These technologies require a much shorter learning curve than Windows Phone 7 and were mostly add-ons to things most .NET developers were already doing. The fact that Microsoft seems to not be putting as much effort into Windows Phone 7 is a critical mistake.

Motivation to develop

The first three issues all add up to being a very high barrier to entry for the prospective Windows Phone 7 developer. In and of itself, that can be overcome. Developing for the iPhone originally required owning a Mac, learning Objective C, and buying a handset only available on one carrier, and yet its development base exploded very quickly. Clearly, barriers to entry are less of a problem if developers are motivated.

When the iPhone debuted in 2007, the world was a different place. In the United States, the smartphone market was practically dead; the phones were ugly, hard to use, expensive, and no one wanted them. The iPhone was the only smartphone worth buying, and the demand for quality smartphones was so high that the devices sold really quickly. People were making a year’s salary in a few weeks by writing iPhone apps in their spare time. When Android hit its stride with the release of the Motorola Droid, it met the needs of potential smartphone customers who wouldn’t or couldn’t get an iPhone for whatever reason. As a result, it got market share and developer mindshare.

But what does Windows Phone 7 offer to a potential developer to justify trying to work with it? The Kin debacle proved to us that Microsoft can’t advertise its way to sales; it also showed us that a half-baked product might have been a success in 2007, but not in 2010. And we already know that Windows Phone 7’s features are not comparable to the typical Android phone (which include tethering, removable storage, copy/paste, multitasking).

Based on the newly released photos, the Windows Phone 7 handsets are uninspiring to say the least. The specs are not impressive, the designs are lackluster, and the most interesting of the bunch features slide-out speakers. Yawn. The Palm Pre with the new WebOS was considered a good device with some flaws by analysts, and like Windows Phone 7, it was coming from the trailing position. Even though folks liked WebOS, the Palm Pre and the Pixi were marketplace disappointments. In other words, developers have zero reason to believe that Microsoft can achieve any kind of momentum with Windows Phone 7.

The HTC Surround, a Windows Phone 7 device


I want to see Windows Phone 7 succeed (I think Android and iOS need some real competition, and I do like what I see in Windows Phone 7), but from the developer’s viewpoint, the Windows Phone 7 story comes up short. It’s a shame Microsoft made so many mistakes in the run up to Windows Phone 7; these missteps will very likely cost the company millions of dollars that they’ve dumped into this project.


Disclosure of Justin’s industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.