The current state of the Microsoft development world is interesting, and as usual, ever changing. However, due to this ever changing environment and some bad messaging coming out of Seattle over the past 6 months--maybe longer if you include the future of Silverlight and WPF rumours--I'm finding it hard to stay solely and .NET developer and harder still to remain solely a Windows developer. Allow me to explain.
Since Christmas I have been working almost exclusively on software designed to only run on Apple hardware, specifically iPads. I have had to learn to use a Mac, work with software and environments nothing like the familiar world of Windows, which I have used almost exclusively for coming close to 20 years now. Seven months on and I can honestly say I've given the Mac world a fair crack of the whip, my opinions on the OS and environment are now based on working within this Apple environment (iOS, XCode, MacOS) day to day and not from a biased Windows developer viewpoint.
Developing with Apples in Mind
And honestly, it's OK. Not fabulous, not ground breaking, not better, not worse--both OS's, development environments and companies have their issues on a day-to-day basis for me as developer that kinda cancel each other out--so it's just OK, I get what all the fuss is about, but still, it's OK. Would I be happy to spend the next 2+ years working on a Mac? Yeah, sure, why not; maybe after that time I would stop being a Windows developer using a Mac and actually a developer using a Mac.
Prior to this current development project with iOS I spent most of the previous year designing and building a Windows WPF application from 'File->New Project' to something that you can download and buy today; so when this opportunity came about I was fresh and ready to try something completely different--but not too different, as you will see. As with most .NET shops looking to move into this iOS world we were faced with a difficult decision: should we go native and use XCode and Objective-C from the word go? We decided native was a bridge too far at that point.
We chose to get started by using Mono and MonoTouch, which enables you write iOS applications by using the C# programming language and provides an implementation of the Base Class Libraries (BCL) that usually ship with .NET making the development process somewhat familiar and extremely productive for your average .NET developer. The alternative was to learn a new toolset (XCode), new language (Objective-C) and a new OS (iOS and MacOS as I had seen and used neither before this project started) all at once, which is a big ask on small timescales. It was a no-brainer for us, especially for the money, Xamarin is not free, but if you're serious, it's not expensive either.
Seven months on, two releases into the AppStore, one prototype based on the same codebase, and currently in development two new versions of the same app for a very large and well known company, with more opportunities in the pipeline, I think we made the right choice--I think we're very close to calling the project a success. At this point I can put my hand on my heart and say if it were not for the Xamarin tooling and software we could not have pulled this project off. Having said all that though, I felt at the beginning of the project that using MonoTouch was a stepping stone, a way to get us started, but not the final goal. I always imagined that we would, and should, get to a point where we would go native and convert to Objective-C. I still believe that to be the case seven months on, and I am actively working on those skills now ready for the transition. At that point we can leave the managed and .NET world completely behind and go native.
Why? Why bother? Well, I think it scary to get started on a new project with no idea if you can make it work or even if the idea makes sense, to then decide to commit to more risk by throwing in so many unknowns is not a sensible strategy, certainly not one designed to succeed; however, you have to balance the benefit over the cost and effort--don't get me wrong here, Xamarin are amazing, their products are amazing--but we have a new risk now, now that our development has matured and reached a point where we know we want to continue and make more money from it. The risk is that we rely massively on a 3rd party. What if they decide not to do it any more or go under? What if Apple change the rules (again!) and make it impossible for Xamarin to work their magic? The other aspect, however for a profitable business a minor one, the Apple tooling is free, for Xamarin we have to pay for me to write code. In fact Xamarin are very smart, and it shows in their pricing--we're ready to think about another type of application deployment: the Enterprise and with this comes a 3 time increase in our costs for Xamarin. So I think we need to go native, and soon--like now.
Developing with Windows in Mind
This brings me neatly to the world of Windows and why I don't think I can ever solely be a Windows (desktop) developer again. Personally, I think the world of the Windows desktop is fairly stable and will remain so for some time. I think if you're building Windows applications for the desktop today and you're a .NET shop WPF is the way to go, and I don't think you'll be sorry. That message may not be clear coming out of Redmond, but I think that is what is being said by listening to what they are not saying. By that I mean there is a tendency to talk about what's new and shiny, exciting and different--WPF is a little too long in the tooth now for it to be that. I cannot remember the last time I saw on a conference list, in a news article from Mary Jo, or some 'super secret project' that someone was developing a new COM iteration or updating IUnknown, but all the latest WinRT and Windows 8 code is all COM, Groundhog Day for Don Box. Speaking of Don Box, a wise man once said:
"COM is not dead, it's just done."
And while I don't think WPF is "done", I think the initial frenzy is over and maturity is the order of the day.
The mobile market is somewhat different however, and in this new XAML world first seen in WPF, later in Silverlight, now in Windows Phone and WinRT staying in the managed world is much harder. In past incarnations XAML was solely the domain of the managed developer, it required that you use a managed language such as C# or VB.NET; this is not so in the coming wave of platform development for desktop, tablet and mobile. XAML is also in the hands of the native developer. And so it should be, XAML is a great technology.
But what does this mean? I think it means that more of us will become native developers (again! for some of us, depending how old you are or which school you went to ;), this is opposed to more native developers using XAML. What do I mean by staying in the managed world will be harder? I've been working on a game for the Windows Phone called Maze, which uses XNA, which is a bunch of managed wrappers around DirectX. There are two approaches to building apps for Windows Phones today: Silverlight or XNA; typically you use XNA for games and Silverlight for applications--in Metro, on the desktop, this will not be possible--we don't yet know if Metro on Windows Phones or Surface tablets will support XNA, as there's been no clear messaging around that, but the that fact that it won't be on Window 8 Metro desktop I strongly suspect the future is bleak in Metro world for a managed DirectX solution. Therefore, if I want to put my game in the Marketplace for Metro I need to rewrite it, either using native DirectX or with WinRT, which could be done with managed code. So now I'm learning DirectX with C++, again, going native. Beyond this immediate need I think learning to 'go native' will have a much longer and sustainable story for any developer to tell as time moves on, and as more tech emerges from Redmond. While I strongly believe that there is much support and love for managed code in many areas of Redmond, if you're a Windows developer, and that now means a phone and tablet developer too now, being able to go native will stand you in very good stead--if you add XAML to that I think you're VERY well set for the future.
Where are we?
Development today has not changed much, the devices and what the term 'computer' means have. This means that for me to continue to work at my craft my skill set needs to change, I need to go native, maybe you do too.