Tim Long

COM versus .NET

I’m always getting into spirited discussions with certain people about the relative merits of COM versus .NET and how the development of a particular set of software libraries ought to proceed.

Actually this is a non-debate; it is totally the wrong question. This is largely a non-debate because of COM Interop which, while not perfect, goes a long way towards ensuring that COM and .NET components can freely interoperate with each other. You write an assembly in .NET, that’s automatically visible as COM interfaces too. Want to consume a COM server in a .NET application, no problem, just add a reference to it and Visual Studio wires up all the necessary plumbing.

But nevertheless, I believe that most new development should focus on .NET unless it absolutely, positively must be done in COM for some arcane reason. Even when creating new COM components, that is probably best done in .NET. When I say this to someone who has a lot of time and money invested in COM technology, they usually get quite defensive and don’t wait around to hear my reasoning. I get accused of wanting to throw away all existing software and write everything all over again, from scratch. Well, that isn’t true. I’m just not that naive. You only have to look at Microsoft’s products that are riddled with COM – Windows, Office, Visual Studio, Exchange Server, SQL Server, the list goes on – to know that Microsoft is never going to spend the time and money to re-write all that code. New products are a different matter. Some of Microsoft’s products are all managed code – like Microsoft Dynamics CRM for example, which has .NET running through it like a stick of Brighton Rock.

So why, then, if I agree that COM isn't going away and that we can’t throw away existing code, do I insist that new development should use .NET? My reasons are twofold:

1. Developer attrition
2. Tooling and innovation

This can be summarised by one simple question: When is the last time Microsoft introduced new technology to make it easier for you to develop COM components? The last real innovation was probably the Active Template Library over a decade ago.

I see the worlds of COM and .NET as two desks, back to back, with a glass partition between them. Over there on that table are COM components and tools, over here on this table are the .NET counterparts. The glass partition represents COM Interop. Each side of the glass partition can see everything on the other side, but developers are generally either on one side or the other. They can’t easily be on both sides of the partition at once. If you’re a .NET developer, you can see all those COM objects through the glass, but you probably don’t know what’s inside any of them and there is this annoying barrier that kind of makes it hard for you to understand what makes up a COM component. So you probably won’t bother. If you need a new component you will just write it in .NET and expose that to COM through COM Interop.

I always get the “COM isn't going away” argument. You know what? I know. And I don’t care, because that isn’t the point. We already covered that. New programmers are learning Java, C# and VB.Net using modern IDEs like Visual Studio. I remember back in the mid 80s spending several weeks writing all the chrome for a new application, all the the windows and menus needed to be wired up by hand, no events, everything happened by passing messages between mailboxes, every message had to be recognised and handled manually, every last detail had to be wired up painstakingly by hand. In those days, programmers didn't eat quiche. Today, those weeks of work take about 10 seconds in Visual Studio. File… New Windows Application… Done. Microsoft is busy churning out world-changing development paradigms like ASP.Net, LINQ, ADO.Net Entity Framework, ASP.Net MVC, ASP.Net Dynamic Data, WPF, WCF, WWF, Silverlight. Developers will (and should be) be drawn to all that new cool stuff like moths to a flame. And rightly so. Who wants to waste weeks reinventing the wheel? How many new developers will want to learn about COM and C++/ATL? I bet the answer is close to zero.

So, I agree: COM is not going away, at least not anytime soon, if ever. Even if Microsoft releases their research prototype “Midori” operating system, which is managed code all the way in to the kernel, they’ll probably have to provide a compatibility layer for COM (the Necker cube will be flipped, but the end result is the same). There is just too much stuff out there – including Microsoft’s own stuff – that relies on COM. So we totally agree about that.

But, again, that isn’t the point. COM isn’t going away, but the developers are and so are the development frameworks and tools. The point is that no-one but a few gnarly old die-hards will be developing new COM stuff in the future unless they absolutely positively have to because they have no choice. And they are going to have the choice. It just isn’t going to happen. Developers will not be interested in learning or using COM ussing clumsy outdated tools or in getting jobs doing COM programming – so you will have no COM developers. There is a looming skills shortage in the IT sector (http://www.manufacturing.net/News-Technology-Worker-Shortage-Worries-Businesses.aspx http://news.bbc.co.uk/1/hi/business/688138.stm http://news.bbc.co.uk/1/hi/world/south_asia/714346.stm). This means two things:

1. The quality of programmers is going to go down the toilet and the new breed of Java Kids will not have the patience for complicated arcane stuff like COM.
2. Real soon now, if not already, it is going to be a sellers’ market and developers will get to pick and choose what they work on. And you know what? None of them will pick C++ or COM, they will pick the easy, productive, cool new stuff that makes them look like rock stars.

So, if you still want to develop new software using COM, then good luck with that. But you see that brick wall in the distance? You might want to think about hitting the brakes before it gets much closer. Organisations that doggedly stick to the “COM Isn’t going away” mantra are completely missing the point and they are going to die by attrition. There will come a point when – even though COM is still in Windows and much of Windows is still written as COM components – they can’t find developers who will be able to maintain their code or even want to.

Share this post: | | |