Claudio Lassala's Blog

One of the main roadblocks I see for several .NET companies and developers to get into Rails is the matter mentality. For somebody who has been doing .NET development for several years only doing it “The Microsoft Way”, not looking outside of the box, getting into Rails can be a total nightmare.

Company-driven or Community-driven

.NET and Rails are produced by people with different goals in mind: the first comes from a company who wants developers to produce software for their operating system and devices, whereas the second comes from developers who need to ship software.

It doesn’t look like the people within Microsoft actually use their tools to build real world software, which causes tools and frameworks to not exactly address difficulties developers face out in the wild. Everything I’ve seen in Rails development has been quite the opposite: it’s all built because of a real world need.

Open Source

Rails is totally open source: which means that if somebody finds a bug, a vulnerability, etc, the patches make into the framework as soon as possible. If somebody writes a nice feature, there’s a good chance it can make it into the official release of the framework. 

As far as what I’ve heard, even though the source code for the ASP.NET MVC is available for whoever wants to get it, Microsoft does not accept community submissions. It is true that the product team seems to hear feedback from the community, but such feedback may or may not, one day, make it into the framework. Microsoft is too big of a company, and as such, even simple changes may take forever to be even considered.

Gems

Ah, the gems…

For several mundane things we need in applications, there must be a gem available out there (.NET developers can think of them as “components”). Authentication, authorization, avatars, image handling, you name it. As far as what I’ve seen, the Rails community doesn’t suffer with the NIH (not invented here) syndrome; these people embrace the idea of “let’s not reinvent the wheel every time”; if there’s an open source piece of code out there ready to rock, let’s use it.

In the .NET world, even though there’s quite a number of things available in open source, most people and companies just don’t embrace it. “We won’t use it if it doesn’t come from Microsoft“, is what you normally hear. 

Testing

Testing is something that the Rails community just take for granted. It’s a no-brainer. The framework is built with testability in mind. Books are written the same way. Gems (provide either helpers or good documentation (or both!) so that developers can easily write tests for their applications that use these gems.

Because testing is such a first-class citizen, tools and frameworks make sure that writing tests is as frictionless as possible.

What’s the testing story coming out of Microsoft? MS-Test? Oh, please. What about all the sealed classes, and things that are nearly impossible to test (unless you use tools such as TypeMock)? We know of a couple very smart MS developers who are advocates of testing, but the company as a whole doesn’t send out a strong message about its importance.

SubSpec has certainly helped my experience with writing tests in .NET apps a lot. However, it is still running far behind Cucumber/RSpec.

A lot of people may think of tests as “oh, yeah, Assert.AreEqual(4, 2+2), big deal…“, but that’s not it. Behavior Driven Development helps a lot with understanding what’s valuable to the client, flushing out details of the requirements, planning how features are built, tracked, related… It helps with making sure that we only write enough code to deliver the features that are going to make the client happy. My perception is that a lot more Rails developers than .NET developers understand that. If there’s people who understand and follow these practices, as well as tools that remove any friction in doing so, the likelihood of success for a project is much higher.

Object-Relational Mapping (ORM)

ORM is a non-issue in Rails. If you are on a relational database, you use ActiveRecord, and if you are on document database, you use Mongoid or MongoMapper. The main point is: nobody goes off and creates their own ORM component. Regardless of whether you are on a relational or document database (or both), the object model of the ORM options is very similar, so there isn’t a big learning curve going from one to the other.

Also, I have seen some really clever and clean ways that the Ruby language allows for models to be written in such a way to really promote the idea of “thin controllers, fat models”.

In the .NET space, ask half a dozen developers what they use for data access, and you may hear 6 different responses, including Raw ADO.NET (connections, DataReaders, DataSets, etc.), Entity Framework, Linq to SQL, NHibernate, CSLA, home-grown framework, or a variety of other ORM frameworks out there. Don’t get me wrong: diversity is usually a good thing, but in this case, I believe it does more harm than good. The differences in how all these frameworks work are so big that a developer who knows one of them can’t really easily switch over to a project using a different one.

Source Control

At this day and age, a source control system is a must for anybody doing software development, regardless whether it’s a company or an independent developer. The question then becomes: which one to use?

The default one in .NET is TFS. The default one in Rails is Git. I’ve seen few .NET shops use either Git or Mercurial, and I have seen Rails shops using either Git or Mercurial, but I’ve never seen them use TFS.

I’ve used TFS every since it first came out (5 or 6 years ago?). It’s been painful, every time I needed to install it, and it’s been painful every time I needed to work in a team of developers using it. Problems with files or changes getting lost, weird merge problems, weak support for “branch per feature”, etc.

I started using Mercurial about 8 months ago, and spent another 3 or so on Git, and for the time being I’m sticking with Mercurial (I’ll save the “why” for another post).

What I like about these Distributed Version Control Systems (DVCS) is the idea that I can install and have them up and running within 5 minutes. Using it on a daily basis for normal things (commiting changes, branching, merging, pushing to a remote server) is pretty much frictionless. The idea that I can do all of this locally, without having to deal with remote server all the time appeals to me. Also, being able to easily pull or push changesets between branches, remote servers, etc, is something I like a lot. 

Notice I only refer to TFS’ source control features (or lack of) here. As a source control system, I’ve grown to dislike it very much (choosing words so this post can be rated PG-13 here…).

Integrated Tooling

A common mindset in .NET development is: let’s use only tools that are fully integrated into Visual Studio. I personally think that’s a bad idea. The “Visual Studio is Busy” toast message that pops up quite often just reminds me of that. What’s the problem with switching over to a command prompt to execute some commands (build, run tests, create branch, commit, etc) and avoid being stuck just because pretty boy “is busy”? The more integration, the more likely the tool will be busy doing things you may not care about 80% of the time.

In Rails land, people seem very comfortable with using whatever tools make them feel more comfortable and productive doing their daily job.

Summing up

I’m still very young into doing Rails development, so I may still not be ready to give educated, well-informed, point of view on this difference in mindset, so I reserve the right to change my opinion within just a couple of weeks or months from now. 🙂 

My main point in this post is: this is the perception I have on this subject today, and it does look like the mentality is very different in these two camps.