Retrospective – a year as a Ruby on Rails developer

I spent the last year or so working on a Ruby on Rails project and now I’m back in the .NET realm again. I’ve been asked to write about what that year working on a new platform taught me and how I’m applying it to .NET, so here goes.

I love the Ruby language

I really really like Ruby as a language. You can write good code in Ruby and you can write good code in .NET. But I can write much cleaner, succinct code in Ruby because the language has fewer restrictions. I can do all of the same things in .NET, but it might require factories, dependency injection, code generators, etc. The code ends up getting the job done, but there is a lot more code and it’s more complex. The best example I can think of is a set of factories that create objects for unit tests. I’ve seen many implementations of this in .NET, but none have approached the simplicity of factory_girl in Ruby.

UNIX command line

UNIX is very command-line driven and it’s designed to be that way, so you can do a lot from the command line. You can do a lot with the Windows command line too (certainly with Powershell), but for the first time I really mastered the command line, and I really liked it. Now when I’m in Windows I pretty much use the bash shell that gets installed with Git for almost everything.

On switching from .NET to Rails

I really like Rails, but Rails is different from .NET in a lot of ways. I had no trouble coming into an existing Rails team and picking things up quickly. There are a lot of similarities between Rails and ASP.NET MVC. But if you want to take an existing .NET team and all start doing Rails, you definitely are going to want to bring someone with Rails experience to help you. You have to learn a whole new stack (because Rails runs on UNIX). The patterns and techniques are the same, but learning a new toolset will take time.

This doesn’t mean that teams shouldn’t consider switching to Rails. I’m just saying that while that might be a worthwhile idea, it’s going to take some work. But now that I’ve gone through the exercise, if I had to start a new project and was either working on my own or could choose a team to work with me, I would go with Rails because I feel it’s easier to do things.

Ever changing frameworks

Rails is open source, and there literally is a gem for everything. The problem is that all of it is constantly being updated. So if you decide to use the latest version of Rails, there is a chance that all gems won’t work in the new version. The same problem happens when you try to upgrade to a newer version of Rails – now certain gems won’t work, so you upgrade those, and now other gems don’t work. It’s not a showstopper, but it gets annoying at times. At the same time, I’d rather have this problem than having to write more things by hand myself.

Your process will determine your effectiveness, not your language

It may be true that it’s faster to develop in Rails than .NET. But what has much more impact is how you develop software. You can write good code in .NET and Rails and you can write bad code in .NET and Rails. If you have shoddy requirements, if you are relying solely on manual testing, if your business users can’t tell you what they want, if your team is not writing high quality code, or if there are other impediments that keep you from getting things done, your effectiveness will be limited. Regardless of what platform you’re on, working on improving your development process because that is ultimately what will determine your success.