David Chappell


Get the Feed! Subscribe

Quantifying Complexity: .NET vs. J2EE  
# Wednesday, December 20, 2006
Lots of people believe that developing applications on the .NET Framework is less complex than developing equivalent functionality on J2EE. Beliefs without evidence are just bias, however, and accurately measuring the relative complexity of these two platforms is hard. Finding objective, quantitative evidence for or against this belief isn't easy.

That's why I was so interested in a conversation I had recently with a senior architect at one of the global software development firms. He told me that to bid on projects, his firm first does a detailed requirements analysis of the problem, determining how many function points the solution will require. They then quote a price based on this commonly accepted measure of complexity.

Here's the interesting part: His firm, like all the big software houses, is happy to build the solution using either .NET or J2EE--it's up to the customer. But if the customer chooses .NET, the price is 28% less than if the customer chooses to build the same solution on J2EE.

Why is this true? Why should J2EE be more complex to use? There are a couple of obvious reasons. One of them is that its constituent technologies were created by committees, a process that rarely produces simple results. (Actually, J2EE isn't all that complex for a committee-created set of specs; there are plenty of worse examples.) A second reason for J2EE's complexity is that its creators seem willing to assume a fairly high degree of technical ability on the part of their users. With .NET, by contrast, Microsoft is well aware that it's designing technology that people who liked Visual Basic 6 must be able to adopt in some way. Controlling complexity is an essential part of achieving this.

The latest version of the enterprise Java specs, Java EE 5, made some effort to simplify a Java developer's life. Whether it succeeded in doing this is debatable; opinions differ. What's not debatable is that to be competitive in the long run, the Java platform can't be 28% more complex than its main competitor.

18 comments :: Post a Comment



Your rationale is flawed. J2EE based solutions cost more because the folks developing it cost more. Check out any salary survey...

The interesting question, I suppose, is this: why are J2EE developers more expensive? Part of it is tradition, since employers are accustomed to paying more for developers on non-Windows systems. Supply and demand might play a role in some places, too, although competent .NET developers are widespread today.

Yet it does seem that the J2EE environment is inherently more complex, with more options than the .NET Framework. One can argue whether this makes J2EE a more powerful platform, but the added complexity appears to be real.

And some background: Like its competitors, the global software house this architect works for does most of its development in India and other low-cost locations. Salary differentials don't mean nearly as much in that environment.

Great site, I am bookmarking it!Keep it up!
With the best regards!

Is is a simplistic conclusion.
there are other answers to that choice: They have a large .net talent pool.
J2EE talent is more expensive than .net (maybe because those vb6 developers now say that they are .net developers)
and other reasons.

It looks like developer cost isn't part of the quoted price--it seems to be based only on the number of function points.
It might be even cheaper if J2EE developers were billed at a higher rate.
I doubt that the size of the talent pools make that much of a difference--there are a lot of J2EE developers looking for work these days

I thought that the cost was based simply on the number of function points. Having programmed in both J2EE and .NET environments, that would make sense.
I'm not sure that the size of the .NET and J2EE developer communities have any bearing in the cost difference--there are lots of experienced J2EE developers looking for work (and I know of some who've switched to .NET).

Well, even if that 28% has something to do with J2EE complexity over .NET (I think it is, but complexity is not the only factor); in some cases that amount can be justified by cross-platform-ness.

I was a J2EE developer but now I'm coding mainly on .NET. And I think that J2EE development cost more, too.

in my opinion the reason is due to some useful features like decoration of source code (attributes) and less impedance (like in electricity) between the code and the environment. Decoration is now implemented in Java 5 but the cross platform nature of Java is the cause of impedance and you can't solve this (perhaps with a Java OS).

I think that the difference will remain and I see Microsoft that is working to eliminate other impedances.

You're certainly right, Nguyen: sometimes the extra complexity of J2EE is justified by its cross-platform support. And as the anonymous comment above points out, these two things aren't entirely unrelated. Still, J2EE is more complex in needless ways, too. Microsoft has subsumed diverse APIs into WCF, for instance, while Java EE 5 continues to separate them into EJB, RMI, etc. This is a big reason why, as I've argued elsewhere, the enterprise Java world so needs Service Component Architecture (SCA).

Even though the .NET seems to come in with about a third less less function points, there is still much room for improvement (in Java and in .NET).

In other environments the costers are going to include issues like the developer being able to maintain a "flow mental state". This can make a huge difference to quality and productivity. Unfortunately, in many development shops, it's rare enough that those who make the costings aren't even aware of it!! In that context I think languages that get beyond the mental barriers imposed by conventional OO might have a lot of impact!!

Rarely ever is a conclusion as simple and straight forward as it might seem. This example is no different.

There are many factors that will play into the overall 28% reduction in price and they truly need to be understood as a whole.

For instance:
- They use off-shore labor which is notorious for being below average in skill
- An average cost of .NET vs J2EE developers differs. The numbers become less skewed as the experience increases, but most average .NETters are really VB hackers. The average J2EE (onshore) developer is someone slightly more proficient.
- Using average developers actually increases a projects cost. Expert developers cost more per hour/salary but are worth it when comparing project scope/timeline etc etc etc (basically, expert people are worth the money)

The point of fact remains that expert J2EE developers and expert .NET developers may not differ that much, but average J2EE developers and average .NETters probably do.

I would conclude that using offshore .NET developers has a higher likelyhood of success than offshore J2EE developers because J2EE is traditionally a more powerful and robust platform, but a bit harder to grasp. Using expert onshore J2EE developers and Expert onshore .NET developers would probably be a better comparison

Economics lesson: there is something called value-based pricing. Customers perhaps think that the value of a J2EE solution to the same problem is 28% more valuable. This could be due to many reasons: lower TCO over lifetime, easier maintenance, higher adoption of their product by their end customers, etc etc I pay for Toyota more than what I pay for Kia because of perception (and reality) of better quality. Just perhaps- the customers think that the J2EE solution is of a higher value.

Hello David,
interesting point and point of view.

But, firstly, you should define what complexity **is**.
So ?


In this case, as I mentioned in the blog entry, complexity is being measured in function points. There are other approaches to doing this, but I don't know of any alternatives that are as widely accepted today, especially for cross-technology comparisons like this.

To Anshu: People who choose a Java solution in this case clearly do value it more than a .NET solution. If this weren't the case, they wouldn't be willing to pay more for it.

This doesn't equate to value-based pricing, however. My guess is that most customers who choose the more-expensive Java solution do so to fit in with their existing skills and environment, not because there's an intrinsic advantage in maintainability or quality. It's tough to quantify these things, but my experience is that people who work in both worlds rarely seem to believe that the technologies themselves are so different in these areas.

which one has bright future which language can i study give me some suggestions....

Both the Java language and the main .NET languages, such as C#, have a bright future. Learning either one (or better yet, both) is certainly worthwhile. The language is only a small part of your total learning investment, however. Really understanding the platform (Java EE or the .NET Framework) and the tool (Eclipse or Visual Studio) are likely to take more of your time. Still, it's likely that learning either world will be commercially valuable for you. Which one is a better choice depends on where you are, what kind of work you'd like to do, and other factors.

J2ee vs .Net - The url below explains why MIT chose .Net over J2ee.

Basically the decision comes down to cost savings and technology.

Yes - whatever can be done on one platform can be done on the other.

However, in the commercial world where the money is made, I will go with .Net because Microsoft is more focused on enhancing their platform and intends to keep improving until they beat their competition.

MS .Net will just keep improving their product line and continue to grow in popularity. The outcome is simple as that.


Post a Comment

<< Home