Brick Wars: Java vs .Net

Java vs .Net: Cars & Bricks Analogy
I don’t know who created this original image. I have reached out to Yamil to see if he did. I’ll update the credit here if and when I find out.

Yamil Cabello recently posted this image on Twitter.

It was re-tweeted by the Microsoft Developer account.

I think this image really embodies the differing philosophies of Microsoft and other companies.

If we look closely at the image we see that the Java car is made up of a huge number of super specialized, tiny pieces. The .Net car on the other hand is made of a smaller number of larger pieces.

The crux of the matter is that the person who made the Java car likely spent more time doing so, but was probably able to come closer to exactly what they wanted.

On the other hand, the .Net car had fewer, larger pieces that likely made for faster assembly, but fewer options.

Neither version is inherently “better” than the other. Needs and expectations must determine which approach is “right”.

Of course this isn’t a 100% accurate analogy. I have worked for years with both of these stacks and know that this analogy is only true if you adopt the mindset represented. A Java developer can adopt a framework that is more akin to Lego blocks and a .Net developer can drop down to bare-bones C#, VB, F#, etc.

However, I think the tendency among both camps pretty well lines up with the image’s implications.

For the extreme example I’d offer SharePoint. It is all about snap together bricks. You do have the option of making your own bricks, or course, but there are a ton of bricks to be had.

This same argument could be made for the Oracle database vs Microsoft’s SQL Server.

I’ve spent years with each, and their differences also line up pretty well with this image.

The analogy I’ve always used is cars.

Oracle’s database is a Formula 1 race car. In the hands of a skilled driver with a skilled pit crew, this thing is amazing.

SQL Server is a high-end production Porsche. A skilled driver can do pretty well with it without a dedicated pit crew.

If we put a normal driver in the Formula 1 car or if we don’t tune the car to the specific conditions of the track on race day, it will be smoked by a sports drink fueled teen in a tricked out Mustang. It is quite likely the normal driver will not even complete the race, but rather wind up crashed. Probably on fire.

On the other hand, you can drop a normal driver into the Porsche, and they will likely do pretty well. They will, naturally, have limits, but are quite likely to survive without extreme tuning or maintenance.

Of course if you have a highly trained crew, the Porsche can be tuned as well, but it is not designed to be a formula 1 racer. It has fewer points to be tuned. It is made of bigger blocks. If you want the Porsche to compete then you will need a trained crew and driver.

In both cases the companies involved made design choices. Trade-offs are always necessary when building anything. You can’t build a large house that is also small.

You can also feel the Unix bloodlines in the Oracle database.

The tradition in Unix has always been for small programs that do one thing and do it well. You then chain together those little programs to do more complex activities.

In other words, create lots of tiny, specialized blocks.

The Windows tradition has been more towards large programs that do an entire activity.

Large, generic blocks if you will.

Of course there is a trend now to abandon both Java and .Net (and Oracle and SQL Server) to zip around in tiny, hot-rod go-carts. These kids today!