Kirk Evans is a Microsoft Architect for the Azure Center of Excellence.
Introduction to SharePoint and Azure IaaS
Building SharePoint Apps with Windows Azure Platform as a Service
SharePoint Solutions and Architectures on Windows Azure Infrastructure Services
Understanding Authentication and Permissions with Apps for SharePoint and Office
Every once in awhile, the obvious jumps up at me. It happened today when thinking about how to get developers and architects to adopt .NET. The answer: you don't.
Simple. Don't try to convince them to use .NET. If I start a conversation with a VB6 developer who is holding onto COM until it is pried from their dead, cold fingers by enumerating the benefits of garbage collection and the common type system, neither argument will resonate. If I try to show what reflection is and how cool I really think the use of attributes are to separate concerns, they won't really care.
Think about what they are trying to do and show them how to do it. If they need to integrate disparate systems, don't show them the XmlSerializer, show them a sample using WorkflowServices in .NET 3.5. If they need to write web applications quickly, don't show them how to write ASP.NET custom controls, show them a sample that achieves a result with little to no code.
I bet that statement makes some people (especially the ALT.NET folks) throw up a little in their mouth. I can hear it now, "Oh no, not another evangelist showing drag-and-drop development." That's not what I am saying at all. I am saying to start the conversation by showing how easy things can be, and then show how to customize and implement best practices. People adopt platforms to solve problems with the least friction possible.
Funny, I have done this a bunch. I got a really large telco to use BizTalk in a very large way. I got a media company to also adopt BizTalk, and it has been spreading like wildfire. I constantly see my customers adopting SharePoint, and none of these conversations start with the benefits of garbage collection... the conversation starts by showing how to solve a problem.
When I do demos, I typically start with the low-level code. I like showing the guts of the CLR, I think the common type system and how intermediate language is implemented is fascinating. I like showing the guts of the WCF channel stack and the million extensibility points. I don't like creating web pages because, despite the vast productivity tools in ASP.NET, I still suck at it. I don't like doing Silverlight demos because I don't think with that side of my brain.
I like low-level geekery that is not typically relevant to introducing concepts for the first time. When I show WCF, I can quickly get down to creating custom bindings and channels. When I show WF, I can quickly get to creating custom activities and services. When I show ASP.NET, I am much less prone to showing data binding than I am to dive into the guts of how ASP.NET processes the HTTP stream.
What that means is that I need to change my delivery. I need to work on delivering that message at a higher level rather than diving straight into the guts. And I also need to schedule a few sessions that are intentionally created at spelunking into the guts so that I can get my fix.
I agree with you, one of the service my company provide to local ISV or developers is migrate them from old platform(vb6/asp 3.0) to .Net. THis is the common scenario i face and to kick star the things, you must get them "interest" in the technology.