On The Complexity of Microsoft .NET

by Ciprian Jichici 1. April 2010 06:04

.NET Framework 4 together with Visual Studio 2010 are major milestones in the lifecycle of Microsoft’s complex application platform. Unlike the Java world which is currently experiencing fragmentation (Oracle’s Java EE 6, Spring, others) the .NET world seems to be holding together. Version 4, backed by a strong Visual Studio with a brand new shell written entirely in WPF, looks very solid and appealing from both the architectural and the development perspectives. Well … is it?

It seems to me one can find in almost any situation that leads to software development conflicting perceptions between developers and decision makers. When I say decision makers I’m thinking about those who have to accept and ultimately assume the technical decisions taken during the ALM (Application Lifecycle Management) process. While the former become rather easily enthusiastic about any new technology as well as about as more control as possible, the latter are much more inclined towards stability and, much more important, clear and measurable technology roadmaps. This is why I think that the fragmentation we see today in the Java world is not necessarily a good thing. .NET needs a strong Java as much as Java needs a strong .NET. History says loud and clear that the only way forward is strong and fierce competition.

The interesting question here is whether having a single driver behind guarantees or not reduced complexity in addition to platform stability. Seems to me the answer is closer to no than to yes. Despite being pushed by a single vendor, .NET exhibits many (if not all) of the unknowns that exist in fragmented worlds. Probably the most common unknown is “what’s the right technology to choose here since I have several alternatives?”. It’s true, most technologies that are present in .NET have a pretty clear area of coverage. The problem is that sometimes these areas overlap and it’s not always clear what the right choice should be. Just think about desktop user experience for a moment. Should I bet on Windows Forms, Windows Presentation Foundation, or even Silverlight? Or take the web: ASP.NET Web Forms, ASP.NET MVC, ASP.NET with AJAX, or Silverlight? Sometimes, it’s obvious. But sometimes it is not, and this is why I feel there’s an ever increasing need for guidance here. With .NET Framework 4 especially, the game is not only about learning how every single technology works. It’s also about tradeoffs, compromises, and especially implications resulting from choosing one option over the other.

With newcomers like LINQ, Parallel LINQ, cloud computing, dynamic languages, functional programming, and modeling (to name just a few) we’re now very far from what .NET used to be in its early years. We’re at the dawn of an era where the complexity of the platform becomes a fact of life. Most problems we have to solve have at least two or three different solutions, with conflicting consequences. It’s a world where knowing a programming language and a few basic technologies is not the recipe for success anymore.

To make myself very clear I have to say that .NET’s complexity is not due to any kind of architectural, design, or execution flaw. Au contraire, I think Microsoft .NET Framework (especially version 4) is a fantastic feat of engineering, a living example on how to design and implement complex functionality. The complexity of .NET comes from the fact that it spans an amazing array of technologies, environments, and approaches to build software. For us architects and developers it means that knowing to write .NET code is just not enough anymore. It means we need to dedicate serious time to understand every single option .NET has to offer, to learn the tradeoffs, and to know where the compromise lies in every choice we make. It means to accept a simple fact of life: the power and versatility of .NET comes at the price of increased complexity, and we need to deal with it.

Tags: ,

.NET | Architecture

Comments are closed