Thursday, 1 June 2006

Java and .NET - choices.

I'm not usually drawn to online 'Java versus .NET' discussions.  They tend to attract evangelists and bigots, and rarely lead to any insight.  This article on TheServerSide is a little better than most; there is still a hefty proportion of noise, but enough signal gets through to make it worth reading a selection of the follow-up comments (I have only managed to get about half way through, skim-reading).  Quite a few of the comments reinforce my own views, hence this post.

Software engineering is (or should be) about getting things done - creating and delivering something.  You use the tools and techniques which work well for you, in your environment.  In my view, Java and .NET are roughly equivalent in terms of their ability to enable delivery.  You cannot guarantee success by choosing one technology over another, but you can improve your chances: you select the one which most closely fits your circumstances.  This piece of common-sense at least emerged from some of the comments.  If your business (therefore your customer's) is tightly bound to the Microsoft platform, then .NET probably makes good sense for you, regardless of engineering-purity arguments in favour of an alternative.

The breadth-of-choice issue, in relation to Java frameworks, libraries and technologies (and even IDEs), is an understandable point, but I see this is as one of Java's great strengths. The Microsoft monoculture means you don't have to think for yourself, and for many a jobbing programmer, this is a good thing. What's needed is strong technical leadership where decisions concerning the language, tools and technologies to be used by default are made by senior engineering, following some process of study and selection. With the burden of technology-selection drastically reduced (even removed), development teams can get on with applying the selected technology, gaining experience with it and feeding-back into an iterative improvement process managed by the technical leaders. 

Some will complain that this smacks of a 'two-tier' technical hierarchy, with certain individuals occupying elevated positions and having control of process and technology.  Well, yes, that is exactly what I am suggesting.  I don't see a workable alternative that doesn't result in, at best, less effective teams constantly trying different things, and at worst, complete chaos.  It doesn't mean the leaders are always right, and (as the hint at an iterative process indicates) it doesn't mean things can't change.

This article is timely because I have only recently started trying to use Java and Eclipse, after many years of C# and .NET.  I can sympathise with the .NET enthusiasts because I am at the stage where I know how to do it using C#/CLR but I'm not quite sure of the best way to do it using Java.  As it happens, I don't think the range of alternatives is daunting at all: it looks to me as if I can go a long way with Eclipse (with additional libraries), Spring and Hibernate.  What continues to amaze (and delight) me is the range and quality of supporting libraries in the Eclipse space: there is no equivalent in the Microsoft world.