David Chappell

  • September 2020
  • November 2017
  • April 2017
  • October 2016
  • March 2016
  • February 2016
  • August 2015
  • April 2015
  • December 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • December 2004
  • November 2004
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003

Opinari

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.


17 comments :: Post a Comment

 


Comments:

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!
David
 

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).
 

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 ?

messaoud
 

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.

http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=000tcP
 

Post a Comment


<< Home