.NET or Java: How to choose?

I often see this question on forums and social network groups, so I decided to share my own view on SoftFluent official blog.

To introduce myself, I worked for a company that was acquires by IBM between 1992 and 1997. From 1997 to 2005, I worked for Microsoft, being in charge of developer evangelism in France, mostly around .NET between 2001 and 2005. Since then, I created my own company SoftFluent. And I often advise ISVs in their evolution strategy, sometimes outside the Microsoft platform. For example, I audited the development organization of some Java-oriented software companies, working closely with Zenika on the technical and architecture area, one of the best Java consulting shops in France.

So I have been hanging around with evangelists of both sides, and more important, seen the result on real projects on those platforms. This said, on what criteria should you base a platform decision?

First, when you develop software, you often develop it to be used over a long period of time. In fact, you never really know when it will be replaced. Look at all those Cobol programs that are still at the heart of many banking systems. So it is critical to evaluate the sustainability of the choices and try to understand where the market is going, in non-technical dimensions also.

This argument is the reason why I mostly talk about .NET and Java here. These two platforms have a critical size, and there is no chance that either one could disappear in the foreseeable future. This might not be the case if you chose a more exotic programming language.

#1: Applicability of the platform for your scenarios

The first element to take into account is the applicability of the platform for your application scenarios. I won’t make any debate about performance as both platforms have proven they can handle whatever volume needed for almost any applications. Scaling your business will not be an issue with the underlying technology but rather an application design consideration.

If running beyond Windows is a real requirement (which is not so often), you will have to go for Java, as the support for multiplatform in .NET is only based on market-risky initiatives not fully backed by Microsoft. Microsoft is not platform-neutral and will probably never be.

However, since the Windows platform is significantly dominant, there are many scenarios where this is not an issue at all.

#2: Efficiency of the development platform for your scenarios

If you don’t have a real multiplatform constraint and your applications will run on Windows, and mostly if you do not have a large budget and timeframe for delivering your application, choose the .NET platform. It is clearly easier to implement .NET applications for a simple reason. It is totally integrated and version upgrades occur globally. You have a single framework of about 25,000 base classes that evolve simultaneously, with an integrated development environment.

Whereas in the Java world, not only you will have to gather different frameworks that come from different vendors or from the community, but you will for sure need to adjust this choice over time. This is a significant cost in money and time for Java projects. It is also worth mentioning the risk of choosing a framework that will turn obsolete or become incompatible with other stacks in the future. This explains why dependency injection has become prevalent on the Java platform, whereas it is usually not even needed on the Microsoft platform, except in some very specific scenarios (I will develop this in a future post).

Of course, this is a simplified view, and one could develop more about the advantages of Java for embedded applications or for .NET when you need to integrate with Microsoft Office, but this is the most important point to understand not to get lost in details.

#3: Skills availability in your organization and in your market

Another important consideration that might weight in a platform decision is the skills of the people in your organization. If 80% of your development resources are used to a platform, it would be suicidal to choose the opposite one.

Not only will you need to train them, but very often, the developers are culturally on one side or the other. It is not so easy for many developers to switch, not to mention the sometimes ‘religious’ behavior about platforms, especially for open-source minded people.

One of my observations is that most "clever" engineers tend to be in the Java ecosystem. When I say "clever", I talk about the intellectual power. The issue is that this often goes with a non-pragmatic mindset that leads to over-architect systems and economical disasters. Read this excellent post from Joel Spolsky to understand the issue.

Unfortunately, this over-architecting issue tends to be imported in the .NET world as it gains market share in the higher end segment. And this complexity even tends to be imported in the .NET platform as Microsoft listens to the community. Will the unique programming model promoted at the launch .NET survive in the future? It is not so obvious, as there are now ASP.NET Webforms and MVC, Silverlight and WPF with real differences in the implementation, etc…

#4: Additional business-related specificities

Last but not least, your market may influence such a decision. If you are developing a packaged product for small companies, it is likely that your customer will be targeted by Microsoft somehow, and there might be specific partnership opportunities to choose the Microsoft stack.

On the other hand, if your market is mostly Java, like in the telecommunications or government sectors, it might be easier to sell and market a product developed on Java.

#5: Using several platforms?

In some cases, it might be relevant to use different platforms for heterogeneous scenarios. If you have mixed teams and the critical size for it, it can be a good way to get some emulation between teams and fulfill scenarios that involve interoperability.

By the way, it is likely that one will have to deal with multiple skills as new platforms get traction, for mobility or social networks support. iPhone has already become unavoidable for many businesses and a platform such as Facebook could gain some significant traction with developers in the relatively near future.

Feel free to comment on this post or share your experience to complete my view.

Daniel COHEN-ZARDI

SoftFluent adds support for the Windows Azure platform in CodeFluent Entities

SoftFluent announced that it has included support for Microsoft SQL Azure into CodeFluent Entities, the first development tool allowing you to transparently deploy over an on premise database or a cloud-based database. Thanks to its simple non-UML model-driven approach, CodeFluent Entities gives developers the maximum flexibility to get their application running in any web, rich or smart client architecture, while allowing the persistence layer to be transparently deployed on an on-premise database or on SQL Azure in the cloud.

Read full press release

Our case against debugging

For quite a long time, we have given the opinion that debugging was costly and not really productive (See Simon’s post Debugging process considered harmful back in 2003). Part of this position is the result of an experience that we like to do with our customers. We enter a room full of developers and we count the number of developers found "debugging" and not writing code. We have reproduced this experience several times, with various customers, and noticed that about 50% of project time is spent debugging and not producing code. And we are not even talking about the testing process here. Amazingly, we have recently seen a question on a LinkedIn group about the time spent in debugging, and 50% was the number mentioned as the first response to this thread by a developer. By the way, we need to congratulate the guy for pulling out this number as he is fully aware of where his time goes, which obviously is not the case for many developers.

So why is this so bad to spend half of developer bandwidth in debugging and how can we develop without debugging?

The main reason would be obvious to a financial guy. It is the "capex" versus "opex" difference. Debugging is an operational expense. Once you closed the debugger, all that you have learned vanishes and your time has been spent without any remaining value. As a comparison, imagine you have spent the same time putting appropriate tracing in relevant functions, outputting the key parameter values to a relevant file in a manner that can be reproduced and configured. You will get the same benefits as a developer to check that your program does what it should and detect potential mistakes. But at the same time, you will have prepared future analysis once the program evolves. Tracing is a capital expense.

Pushing the reasoning a bit further, one can easily understand that this is also a matter of team versus individual vision. The investment put in tracing will benefit to everybody while the debugging approach is an individual process that cannot easily be shared. As an example, I had a "magnetic resonance imaging" exam last month, and I was surprised and happy that all this exam was actually recorded and given to me on a CD. I am now able to share it with my usual doctor as well as any specialist that I would like to have a second look at the exam.

Similarly, it is also a matter of developer machine versus production environment. As computing gets more and more complex, with server-based and cloud-based infrastructure, as well as load-balancing or security constraints, the developer desktop – although simulating those infrastructures – will more and more differ from the real execution context. The risk of not being able to debug some scenarios is higher and tracing is often the only real option to understand what is happening. By the way, think about what is happening with airplanes. We have very powerful simulators that can simulate anything one can imagine. Still, we put black boxes in aircrafts to understand what happened under unpredicted circumstances. So tracing has to be done anyway.

Another more subtle collateral damage of debugging, for certain developers, is what we call stupidification. By hitting the F5 and F8 button convulsively trying to observe what the program does rather than control it, some developers tend to forget the sense of what they are doing, resulting in non-sense programming. Believe us, it is very hard to figure out why some instructions have been placed when they have been entered quite mechanically without any real thinking beyond the fact that this variable should have this value at this very specific step.

To be fair, it is worth mentioning that there are specific cases when debugging can be useful, but it should be the exception, not the rule. Also, we should recognize the progress made in debugging, especially the Intellitrace feature now available in Visual Studio Ultimate. It somehow addresses one of the issues made here, especially the ability to share a specific debugging scenario with the team. But it also tends to maintain the afterthought approach of debugging so this does not change our overall position at SoftFluent.

We hope that an Autotrace feature will appear someday within Visual Studio, so one could get with minimal effort the whole tracing deployed in the real production environment with appropriate configuration options. All the tracing infrastructure is already there and is pretty easy to leverage (see Using CLR 4 Event Tracing for Windows along with application ETW) but the development tool could propose us options to automate the tracing of the stack parameters and their values.

SoftFluent will start sharing its long .NET experience on this blog!

For years, we have been delivering Microsoft-based development projects, as part of our experience within Microsoft Consulting, as well as before and after.

.NET is now about 10 years old, but our observation on the field is that many projects face huge challenges in finding their optimal delivery route. Since the creation of SoftFluent in 2005, we have led more than 50 .NET software audits, for software companies or enterprises, most of them showing that the market still struggles in finding the optimal .NET implementation schemes.

Our understanding is that the huge freedom allowed by the .NET platform (as well as Java by the way) also translates into many possible traps, aggravated by the fact that each project tends to define its own way of implementing its overall architecture and tooling.

Combine that with a trend to get less senior people on projects (as development shifted to off-shore countries) and the fact that technology has become richer and more complex, and one can easily understand that there is no real reason for the situation to get any better in the foreseeable future (apart from our CodeFluent Entities solution Sourire but this is another story with its own blog).

So this is the reason why we decided that it is time for us to share that we have learned about .NET engineering over the past decade on more than 500 projects through posts that we will publish in this blog.

We will articulate our experience about .NET software engineering along the following topics:

  • Measuring software development performance
  • Development team management
  • Software testing best practices
  • Production-aware programming
  • Software maintenance and evolution
  • Software methodologies & design
  • Leveraging third-party code
  • Software engineering tooling
  • Off Shore development
  • Trendy patterns that can kill you

One could legitimately wonder what the last topic is all about. Well, this last topic will focus on implementation patterns that we observed as the “trend” but that we do not think relevant for optimal .NET software engineering, some of them coming from the Java community. We will of course argue on those points, but we expect harsh discussions and people that won’t like us, because some of those trends are applied “the religious way”.

Guess what, we do not care much about religion in software, and our only goal is to make sure .NET software engineering gets more efficient and predictable. So field reality is our only driver. And one can of course disagree with us, this is the rule of the game.

Stay tuned!

Daniel COHEN-ZARDI

Follow

Get every new post delivered to your Inbox.

Join 100 other followers