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.