Can you keep the .NET beast out!?
In the Server-Side post Java Succumbing to .NET in my Organization, too much choice was cited as a major reason why .NET may be beating Java in the Web application technology space. It seems Java is too “flexible” and has too many choices for IDEs, frameworks and other ever evolving tools. In other words, there are too many ways to hang oneself.
I believe there’s a lot of truth in this. Choice creates complexity in addition to flexibility. We can look to the principles of good UI design to reason why choice many times is bad. A UI that offers two or more ways of doing one thing is seen as a detriment in the interface design world. It may lend itself to more flexible and powerful ways of doing things (although it very well may not), but it ultimately confuses the end-user, often times killing their memory of how to do the action or hurting how well they can perform the action repeatedly over time. As a caveat to the rule, it might be more reasonable to say that if you’re going to offer another more flexible (ie. powerful) way of doing something, that it stays “hidden”, out of the way from the average user or use case.
Software developers are ultimately the users of APIs (hence user mailing lists), IDEs and other tools, so why should they be any different, especially in the mature Web application space? In Java, there has literally been a framework explosion. Too many frameworks, IDEs and other ways of doing things has the same effect on developers. One person can only be a power-user of so many things until they have to accept they are just a normal user of some systems. Admitting this is the first step to sanity. Continually learning and relearning frameworks and IDEs kills productivity and might endanger projects to failure or missed deadlines. If there is really only one IDE, one set of frameworks and components, etc… projects can often times get off the ground quicker and on the path to completion.
Even within Java frameworks, there is still alot of customization, configuration and code to write to get them to work for your specific project. I’ve been on multiple developer lists for projects like Struts where committers refused to make a change because it was too specific to a particular solution, even though it would have helped the majority of users. .NET handles things like date formatting (and plenty more) “out of the box.” Java framework developers like generalization. There is a refusal in the community to settle for solving 80% of the problem, so it is left open and flexible which takes time to learn, setup and implement. And for many users, this equals a reinvention of the wheel, or let’s just say a re-configuration of the wheel.
I’ve always wondered why more vendors didn’t try to take Java open source frameworks and work them into their own servers, IDEs, and tools in a highly integrated and comprehensive manner. This would ensure a better productivity experience from vanilla products for the majority of developers. I’m sure there have been some major efforts that I’ve overlooked, but perhaps the moment is ripe due to the maturity of newer Web app frameworks.
Flexibility and loose coupling go hand-in-hand. But loose coupling can mean more work to integrate toolsets and components. This takes time and money, and in an everchanging Java world, this integration may have to be happening continually, costing more money in order to re-create environments rather than complete real business cases. Sun has been promoting their Java Enterprise developer tool, which might be a step in the right direction, but Sun has never been good at selling (and in this case, giving away) their products. Java tools may also promote agile methods better than .NET, but if deadlines are being missed and functionality is missing the mark for other reasons, money is being lost, and that’s the bottom line.
This is where I think something like Ruby on Rails (ROR) comes in. (Disclaimer: I’ve never used ROR.) First, It’s a low-overhead solution that still offers some technology flexibility in what database and web servers you can use. There may be areas where it lacks support for certain new technologies but that will certainly change in the near future. The most important part about ROR, though, is its overarching philosophy of trying to solve most problems through consistent convention. Consistency in practice is key to productivity in projects that follow the same patterns and solve the same problems as previous projects; ROR easily solves most web application problems. If you’re a shop that does web applications, than those straightahead projects are probably more than 80% of your business.
Oddly, this philosophy seems to align with how Microsoft development tools and components are designed, with convention and consistency over flexible configuration in mind. (Maybe .NET convention is a side-effect of only reasonably being able to do things one way). The major difference being the ROR community guides their conventions organically while Microsoft guides .NET convention and tools top-down. This means ROR conventions are slower to change but this shouldn’t be as much a problem in a mature solution space. It may very well be a benefit if MS decides to take a corporate technology detour like what happened when they announced .NET.
If technology decision-makers are deciding to go with .NET for productivity purposes over Java, they may well be right; Java programmers may be thrashing to choose and integrate the right technologies, and taking longer to build up momentum on projects with frameworks that are too generalist. If this is the case, perhaps you should make a case for Ruby on Rails. If decision-makers are just sitting by the warm, fuzzy fire of corporate hype that surrounds .NET, thinking corporate support equals “project success insurance”, you may have your work cut out for you.
(Another disclaimer is that I like to work on complex or newer technology projects that require flexibility, so I often find myself coupling and integrating many components and tools together to get my projects going. I know, I make bad business sense and I’m a total hypocrite.)