Malcolm Davis's Blog

Conflicting mindsets of C# vs. Java

I was recently asked to compare C#/dotNET to Java/J2EE. I began by thinking in terms of features, products, technologies, and then I realized that C# and Java isn't a battle over features, it is over mindsets.

When sitting at the company's workstation, the developer is faced with 2 opposing mindsets:
1. Accepting the tools that are provided on the desktop as the norm.
2. Constantly exploring opportunities for increasing productivity.

Acceptances vs. exploration are major conflicting mindsets. Knowing what is best for the developer, acceptance relinquishes control over the tools and behavior to the manager and friendly vendor. The exploration mindset is the developer looking for, and finding the right tool for the job. Both have their pros and cons.

Tool exploration (in the form of IDE, components, or tools) is natural, expected, and a preferred behavior. As developers, we should explore new ways of increasing productivity by new processes, automating repetitive tasks and component reuse. However, this continuous exploration and improvement is a threat in the corporate world. In many corporate shops, IT policy is to limit installs to the desktop. Many restrict external web site access, and some go as far as restricting access to newsgroups and blogs. [Yes, It is difficult to comprehend that some IT shops even block the blogs at java.net.] These IT shops have many valid concerns. Virus and spyware plague infrastructures. Licensing issues strike fear into legal departments, and many programmers are unaware of the consequences of introducing new software into the environment.

Four years ago, I introduced Ant, Tomcat and JUnit to a major IT shop. The tools significantly improved productivity by making web programming, testing and building simpler and faster. It would seem that every developer and manager would instantly embrace these technologies. For the reasons described earlier, big brother IT brought a stop to everything. [Eventually, many years later, the tools were finally approved in the big IT shop.]

NAnt and NUnit are just a few of the .NET open source counterparts to the Java toolset. However, instead of embracing, enhancing, and integrating the tools into their product line, Microsoft has created their own counterpart called Visual Studio Team System. Change gears for a moment, and imagine if you can, any Java IDE saying, "we are not going to support JUnit or Ant, we are going to construct our own tool set". Hard to imagine? You now understand the different mindset between Java and dotNET. One embraces the realities of developers constant strive for productivity, while the other strives to provide their vision of a single integrated solution. Since corporate IT groups desire a single integrated solution, the Microsoft Team System makes perfect sense. However, the Team System is only about 5 years behind the times, which is about where Microsoft technology base sits.

Those in the commercial world may have started using Ant and Tomcat from the original release on Jakarta. The mindset highlights one of the major differences between commercial and IT development. If commercial software followed the same rules as corporate IT, it would impact their competitive edge, as well as lose their best developers.

As IT shops move forward to adopting external sources for software, generally in the form of Application Service Provider (ASP), Java and open source will become mainstreamed into IT. Microsoft's style over substance approach to software development will eventually bite them. The ASP business model has started us into the era of commercial software development. Industrial strength development techniques, cutting edge technology, and the constant exploration for opportunities to increase productivity, will become the norm, and we will see "the little fish eat the big fish", and see Java eat dotNet's lunch.

Comments

• Tools Governance
  There will always be a struggle between developers and corporations on control over tools. Maybe JUnit, ANT, and Tomcat weren't ready for production when you introduced them? My very first project was based on the 1.0 EJB spec specifically for O-R Mapping. The hype of that product definitely out paced the real productivity gains. If there had been a governance process in place to validate the readiness of technology, we would have saved some time, money, and effort. Corporations must temper tool exploration with sound judgement. It is hard enough developing applications to solve business needs without introducing undue complexity.

  Posted by: john_watts on September 13, 2004 at 05:32 AM

• The vendor is not the community
  Many associate Java to Sun and IBM. Is that fair? Maybe, that's why I say a different mindset. Java prominences would not exist without the likes of Sun and IBM, the same with C# and Microsoft.

  At first it seems really odd to associate languages with companies, until you get out of the development mindset and start talking to vendors, CIOs, etc.. Then just about everybody associate languages with companies. [If a big company backed Python, I think the language would be used more today]

  How the major players interact with the community is now part of the language and what it means to be Java. As evident in Sun's own speech at JavaOne 04, Java is more than features and technology.

  One of the major issues with Java right now is Sun's stock price. Some CIOs have such a strong collation between Sun and Java, that the stock price of Sun makes some in the industry wonder about Java's future. It might be silly, but it's one of the mindsets I have to fight.
  

  Posted by: malcolmdavis on September 13, 2004 at 05:55 AM

• Tools Governance
  I concur that tool exploration must be meshed with sound judgment. One of the classic mistakes is the silver bullet syndrome.

  When I introduced Ant, JUnit and Tomcat to the IT environment, I had just walked away from a commercial company that used these tools successfully. Therefore, it is not the maturity of the product, but an understanding of the pace that things change in development, and how to deal with that pace, that is frustrates me with IT companies. So far, Microsoft has found success in letting other people lead the way.

  In regards to EJB, I understand your frustration. To avoid issues, I make a point not use them with IT shops.
  

  Posted by: malcolmdavis on September 13, 2004 at 06:19 AM

• Tools Governance
  It is not necessarily a C# mind set. As long as I could remember thats how Microsoft has always been. Sure a lot of people would find it conforting to have Redmond look over them like a sheep dog. Your observation about keeping an eye out for improving productivity is also true. One of the reasons I left the Microsoft world behind is because I keep hitting walls which I could not penetrate (for instance why I couldn't have inheritence in COM when I could have it in IBM SOM)

  The other side of the fence I think of as the Unix mindset. Though I have become aware of it more because of Java than anything else, today I think of myself more as a Unix user than a java programmer. I have embraced unix's philosophy, its mindset and its world view and I hold it to be true.

  Nevertheless, I do not entirely understand your frustration with EJBs. I have had the forture (or not) of being part of a project that has been going on since 2001. It started off as being a simple O/R solution based on IBM's then Persistance Manager tool in VisualAge for Java. It was then quickly moved to Websphere 3.5 with EJB 1.0 (Session and CMP). Productivity during those days was quite poor since the team had to get to grips with EJB and VisualAge toolset. The team managed to get it out nevertheless.
  Performance was not stellar but the hardware compensated. Today, we are migrating the application to Websphere 5.x with EJB 2.0 (cmp, cmr, warts and all). Our 100+ odd entity beans pose no problems since we are quite versed in WSAD. To get to this point we had since Websphere 3.5 been to 4.0 as well. Come january we will have 2.0 and tons of new features in the application (mostly on the user interface side).
  This project has seen the use of EJB 1.0. 1.1 and 2.0 (and quite possibly 3.0 when it gets here).To a great extent EJBs have delivered the promice of maintainability. I for one am glad I stuck with the choice. Things have been getting a lot better.

  Posted by: suhail on September 13, 2004 at 11:41 AM

• other mindsets
  I agree that there are two mindsets in the software development world as far as tool choice and technology choice and security choice goes. There are also two mindsets as far as development shops are concerned. There are the Corporate IT shops and the Commercial Software shops. The former is focused on process while the later focuses on product. You can divide the Corporate IT shops into three groups also; internal IT shops, and external (outsourced) IT shops, and third-party IT shops that provide the "standard" software everyone uses (Microsoft, Oracle, Sun, IBM, BEA, etc). They have very different focuses as well. All are process-heavy, but the internal shops are in the business of fulfilling requirements, external shops are in the business of billing hours, and the third-party shops are in the business of market share. None is in the business of producing quality software. Sure, they will TELL you that's their purpose, but they seldom offer incentives that have anything to do with software quality. No corporate IT shop can even hope to compete with a commercial software shop that follows an agile process focused on quality, speed, flexibility, etc. That is the main reason little fish eat big fish every day (and always will).

  Posted by: terryjames on September 13, 2004 at 07:04 PM

• I read your entry "Conflicting mindsets of C# vs. Java" thinking that I'll at last be able to read an unbiased article comparing the two products. I guess, I forgot that fact I am in weblogs.JAVA.net.

  I use .Net. I use Java. I like both technologies. Both promotes RAD. And both improve developer productivity. Both have their pluses and minuses here and there.

  To focus on "tools exploration" is important though it is limited by the target platforms. When you have the tools in your inventory, "tools exploration" stops (and waits). In most cases, given a project, you must stop exploration and decide depending on the availability or the affordability of resources.

  To focus on "increasing productivity" is equally important but, more likely, unlimited by what is available. It may never stop and should continue to do so as new technologies, best practices, models and architectures are developed.

  I believe that Java, .Net and the other emerging technologies are redefining the boundaries of RAD. Come to think of it, for most businesses, it is not just how well or how beautiful you did it. It also matters how fast. Because most of the time, "how fast" defines the cost, the price and benefits thereafter.

  Posted by: e_mendz on September 27, 2004 at 08:53 PM

This work is licensed under a Creative Commons License.