Monday, September 27, 2010

Windows Phone 7: Dead on Arrival

You know, usually I don't count Microsoft out of any game. A friend of mine once said, rightly, that "you can always count on Microsoft to compete against you." If they're interested in a market, they do a nice job of trying to compete in that market. Key word is "try."

As such, they're trying to revive the Windows Mobile franchise with Windows Phone 7. I don't think anything is wrong with Windows Phone 7 from a consumer standpoint.... it might be a fine user experience. But from a developer's standpoint, or as a platform to develop to, they chose a painful road by forcing the platform to be managed C#.

If you read posts by Paul Thurrott, he wrote this one discussing WP7's huge advantage for developers because they use Silverlight. Paul brought out the "developers, developers, developers" mantra. This mantra works well for businesses who develop internal tools. C# is a very convenient language if you're already programming on Windows and in the Microsoft fold. I know that I just arrived at a decision at work because it is much easier to use Visual Studio a lot of the time. But I don't think it will make a difference for WP7.

The smartphone market is now a consumer market. Businesses don't give a shit about them for anything other than email and calendars. The market for "apps" is decidedly one of consumers -- and this is where developers will be focused.

WP7's decision to force managed-only code is about 4 years too late -- the ship sailed on the mobile market and now you must support native code. It's like trying to use C# to ship a desktop Windows app. Know of many? I don't. Almost all desktop apps people use are in C++. The platform was established to be compiled native C code a long time ago, and that's what made sense.

And now we're in the same boat. Apple has successfully appealed to developers and their platform is native. Even though they're no longer #2 in the US (Android took that spot), the mindshare being put into iPhone OS is still huge. Android lags behind on games... why? Because their native API is limited and a pain to use. I mean, come on... NDK developers suggest using JNI to access functions that aren't exposed in the native SDK. Orly? So to play some audio I should have my C++ call Java which calls C? Efficient!

The developers on iPhone now have (if they were smart) lots of C++ libraries they could potentially reuse on other platforms (Objective-C libraries if they were dumb). What does Microsoft propose they do with all of this logic? Throw that all out and start writing C#. Fat chance. If I was a developer like Ngcomo, I'd tell Microsoft to get 20% marketshare first, then I'll get right on that port.

Many people probably think it's early in the mobile phone wars. It's really not. It's been 3 more than years since the iPhone launched and tech moves at a much faster rate than it did with the early PC. The number of devices shipped with these OSes already is mindboggling. 200K Android devices per day... new activations? Only 17 million Commodore 64s EVER SOLD. Android is on a pace to sell 75 MM IN THE NEXT YEAR. They cannot be compared, as Paul did in his article.

At least Google already has an NDK that's working. All they need to do is expose more to it. If Microsoft doesn't have a plan in store for allowing people to develop native code, I just think they're a dead duck on this one.

Sunday, September 19, 2010

Things you should "never" do (i.e. should do)

One oft-quoted blog piece on the internet is Spolsky's "Things You Should Never Do" post, wherein he explains that Netscape made a major mistake because they rewrote their browser from scratch. [Ten years later, the ultimate result of that rewrite is debatable because Firefox is a great product and the result of that rewrite (I think).]

Either way..

It's not the rewrite that's the problem. That's fine when warranted, and often is as codebases go through decades of writhing around with different technologies, figuring out user requirements ad hoc. Many companies have pulled off the rewrite successfully and for the better. Windows is a very good example. NT was a ground up rewrite. It took about 10 years, but Microsoft successfully moved the world's largest installed base of software over to a complete rewrite. Anyone want to argue that getting off DOS wasn't worth it?

How'd they do it? Good technical management, good product management. Overall, just "good management" of the process.

So why does Spolsky call out the rewrite as being something you should never do? The answer is one of visibility.

A startup with poor management--or even a new product at a large company--does not have the same visibility as the rewrite of an already successful product. A poorly managed rewrite of a successful product has visibility towards success and failure... mostly failure. If the rewrite is successful, no one talks much about it (when's the last time anyone brought up migrating Windows from DOS to NT? 2001?).

This is how people like Spolsky can make statements like "never rewrite" and people believe them. Empirically, it seems like rewrites are prone to failure because we see them.

The problem is, it's not a matter of causation.... rewrites do not evoke failure, or even make failure more likely. It just so happens that those are the most notable failures, and seem to make Spolsky's case (Digg is a recent example that brought this topic up again). Meanwhile, many startups with poor management and poor technical choices are currently sinking, unnoticed, as I write this.