ThoughtFactory.CreateThought() A random collection of thoughts from an easily bored developer

Enterprising Solutions

I recently conducted an architectural review that involved talking to some guys who spend a lot of time in the Java space. I'm usually only in able to mix with people from the Microsoft side of the tracks, so this was a great opportunity for me to see how "the other half live". Plus they were genuinely smart, interesting people who were alot of fun to work with, which is always a good thing.

We were discussing various third party frameworks, and the topic of object-relational mapping came up. ORM is a relatively new phenomenon in the .Net world, with things only picking up around 2004/2005 when NHibernate came of age. The Java guys, however, have had production quality ORM systems for a lot longer than folks in Microsoft-Land. Product's like Oracle's Toplink have been around forever.

I often get the feeling that using an ORM is perceived as being more effort than the really, really horrible Microsoft example code and the recommended practice. Your average .Net developer working on Line of Business applications most probably thinks of the practice as a high brow solution that should only be used when you have time (and money) to spare (all while adjusting your monocle and having several hearty guffaws over the latest developments in the Lisp community). Of course, not everyone is of this opinion, but the chances of hearing "that's too much work" or "that sounds hard" at a developer round-table on an average .Net project are still pretty high.

The interesting thing about this is that the Java guys I was talking with had a polar opposite view. To them, most ORMs were the quick and dirty way of getting a data access layer up and going. They even mentioned that any serious work would probably have them looking at writing custom code.

The "build over buy" mentality is not really something that I'd like to see the .Net community aim for, but the juxtaposition of opinions does highlight the relative immaturity of the platform. The Java guys have been using some of these techniques for so long that they're sick of them, while an unfortunate number of .Net developers haven't even heard of them. If this is the impression I'm getting from guys using Java, which itself is a fairly young platform, then I'd be really interested to hear what a Smalltalk developer would have to say on the subject.

You could almost silence an entire room of average .Net developers by asking about taboo subjects such as "unit testing", "layering" and "domain driven design". The lack of (comparative) platform maturity and the relatively low barrier of entry could have a lot to do with that.

It's a shame that some other platforms that don't necessarily play in the enterprise space have had several of these generally accepted best practices available out of the box (complete with strong community support) for quite some time, while the Microsoft space is only just catching up. Not that you haven't previously been able to implement best practice in .Net, but it just generally hasn't been encouraged. "If it's not coming from Microsoft then I don't want to know about it" is an all too common attitude in the community.

Things are getting better, but we've still got a long way to go before strong software engineering and development principles filter their way down into small to medium sized projects, which is where the majority of .Net developers spend most of their time.