Friday, July 04, 2008

Why isn't Microsoft ALT.NET?

My last post: ‘The ALT.NET virtuous network’ has a comment from Ken Egozi: "imo this is all stuff that Mainstream.NET people should do anyway ... I mean - High cohesion/Low coupling? that's software engineering 101" I started writing a reply in the comments, but it soon became a full scale rant so I’ve promoted it to a post. Of course, Ken is absolutely right, why should all this be ALT.NET? Well, by ALT.NET I guess we mean doing things not necessarily as recommended by MSDN and using non-Microsoft tools to do it. If you’re doing Domain Driven Development with Monorail and NHibernate and using Rhino Mocks in your tests then you are ALT.NET. It’s recognition that while the core .NET framework is a powerful beast; easily the equal of Java for example, much of what Microsoft has built on top of it is poorly conceived. So why does Microsoft not encourage good development practice? Partly it’s a symptom of being a monopoly; they commit early and poorly to particular technologies, but partly it’s because they are trying to satisfy developers with such a wide range of skills. I’m an itinerant consultant and have worked in wide range of development shops, many of which have been in blue chip companies with household names. I’ve found that a majority of developers don't know “software engineering 101”. Microsoft’s market research tells them that creating developer tools that assume that knowledge will just confuse many of their customers. It’s well known that the move from classic ASP to ASP.NET was not a popular one with many developers. I know at least two who are still using classic ASP after a frustrating and fruitless attempt at learning ASP.NET. Sometimes Microsoft seems to listening to the ALT.NET crowd, with developments like the MVC Framework. But then Entity Framework comes along which seems to suggest the opposite. So here’s my suggestion for Microsoft: I would like to see them recognize that they have at least two (probably more) very distinct developer markets and clearly mark different tools and guidance for them. One group is what we describe as ALT.NET; Software developers who clearly understand the core principles of software engineering. Microsoft should continue as they have been doing with the MVC Framework for this group: enter into dialogue about the development of the tools and encourage integration with 3rd party and open source frameworks. Another group could be described as the ‘we’d probably defect to PHP’ group, or ‘Morts’ in Microsoft parlance. These are developers who don’t fully grep software engineering 101. It should be clear that the advice to this group is based on this presumption. The core point here is to avoid the situation that many in the ALT.NET group often find themselves in: that they are blocked from pursuing good software development principles or using the best tools because the MSDN documentation is aimed at this group. A majority of developers never look further than the MSDN home page and much of the guidance there doesn't encourage basic principles like HC/LC. Just look at any of the Microsoft official training courses none of them encourage the trainee to learn core programming skills, or even make them aware that they exist. If Microsoft made it clear in their documentation that there is a better way of doing things, but it requires some study to understand, I think it would raise the game across the developer spectrum.


Anonymous said...

Here's a question for you (and perhaps this isn't the right post for the question, but since you mentioned the entity framework, I thought I'd ask): what is the best solution to the object/relational mismatch that preserves the integrity of OOP? We're using Microsoft's auto-generated LINQ data objects in a project at work, and one of the things that frustrates me is having to deal with "entities" that map well to a set of relational tables, but violate OOP principles. Any thoughts?

Chad Myers said...

I don't think we want Microsoft (or any corporation, for that matter) engaged in thought leadership. It will only end badly (and it has).

The thought leadership must come from within by responsible, thoughtful leadership that engages itself with continuous learning, self improvement, introspection, and frequent interaction and exposure to its own community and other communities.

The problem with the community that has formed around .NET and Microsoft is that it is mostly self-indulgent and not very interested in self improvement and change (rather, being comfortable cashing in on speaking engagements, book deals, article writing, etc).

If leaders were more responsible and took charge of their learning instead of waiting for Microsoft to give it to them, Microsoft would follow and deliver appropriate tools.

I believe this is part of what ALT.NET really is: Leaders trying to take charge of learning back from Microsoft (in a good way) and putting Microsoft back into a position where it excels: Making tools. Microsoft should NOT be in the business of deciding which tools need to be made, but instead how to best to make tools that meet the expectations of the community.

In summary: If we hold Microsoft to a lower bar (which we're currently doing), they will deliver lower bar tools. If we hold them to a higher bar, they will make higher bar tools.

Solve the complacency and comfortableness of the community leadership, and you solve the Microsoft tool quality problem.

Mike Hadlow said...

Hi ncloud

If you're fustrated by the limited mapping capabilities of LINQ-to-SQL you should check out NHibernate. It has far more powerfull mapping capabilities and is designed for domain driven development.


Mike Hadlow said...

Thanks Chad, I agree, those are very good points. We need to make sure that the community speaks loudly and clearly in favour good practice and good tools.

Anonymous said...

Hear, hear. What I find crazy about a lot of Microsoft technology is that ADO.NET, WebForms, DataSets - you know, the 'Microsoft Kool-Aid' technologies - invariably get so messy so quickly when you start using them in real life, that you'd probably have been better off starting with something closer to ALT.NET principles anyway.

I sometimes think we'd be much better off if MS focused on the languages, compilers and runtime - effectively supplying the underlying toolset - and letting the community evolve their own frameworks based on those tools.

That said, I really like the community involvement around the ASP.NET MVC framework... a sign of better things to come, perhaps?