The whole debate that I had the other day about .NET developers learning Ruby on Rails stemmed from an earlier conversation about how much more productive you can be in Ruby on Rails vs. Java or .NET. Based on what I keep hearing, I think it’s really hard to ignore Ruby on Rails.

Just to be clear, I have learned Ruby on Rails by playing around with it on side projects, but I haven’t done any big real world apps in it yet. But I have too much evidence in favor of Ruby on Rails.

• People I respect telling me that they estimate that they get things done 4x faster in Ruby on Rails.
• Numerous blog posts (which unfortunately I didn’t bookmark) of .NET devs who took the plunge, decided to do a project in Ruby on Rails instead of .NET, and finished earlier than they would’ve with .NET, even with the learning curve of learning something new.
• A large company had a team that wanted to use RoR for a project, but the company is largely a Java shop and told them no. The team went and did it anyway and 4 months later they were done. The higher-ups were mad and sat down and estimated how long it would take to rewrite it in Java and estimated it at 18 months.

If I were hearing this from just a couple people, I could discount it as fanboyism, exaggeration, or whatever. But I’m hearing too much of this sort of thing.

Just imagine if you could cut the cost of software development to 25% of its current cost. Think of how much money your IT department can save. Think of how much more you could accomplish each year.

Sadly, it seems that very few companies are adopting Ruby on Rails. Maybe they aren’t hearing these anecdotes, or maybe they’re dismissing it as fanboyism and exaggeration. Or maybe they feel that their current IT staff wouldn’t be capable of succeeding or that they won’t want to learn a new language and a new way of doing things.

If we were talking about a slight improvement in productivity, you could easily say that you’re sticking with .NET or Java or whatever because that’s what your team knows well, and I might say that you have a valid argument. But a 4x productivity gain? How can you ignore that? Even if my numbers are exaggerated and it’s only a 2x productivity gain, how could you ignore that?

I hope that IT departments really get serious about this, because a company could have a huge advantage if they were able to complete 4x the work each year. Personally, I really hope to use Ruby on Rails sometime myself because I want to do things this fast. I remember when I first started doing ASP.NET MVC and I cut my usual estimates in half and how awesome that felt. If there is a better and faster way to do something, then count me in.

We had a lively twitter discussion today about whether learning Ruby on Rails is something that would be worth it for the average .NET developer and if the supposed productivity gains that people say that they’re getting from Ruby on Rails only come from the “smart people”. While this is a valid question, I think there is a bigger issue at hand.

The real question is whether the so-called “average” .NET developers are capable of learning new concepts. Certainly the “smarter” developers may learn faster, but I think it’s unfair to say that you have to be “really smart” in order to do good work and learn new things.

A similar argument that I’ve heard in the past is that we should not use certain tools or concepts like dependency injection or unit testing because it will be hard to find developers that understand these concepts or it will be difficult for people to learn them. I’m all for keeping things as simple as possible and not adding unneeded complexity, but if I’m tasked with completing a project, I’m going to use the best tools that I can to get the job done as fast as possible with the highest level of quality.

I think the heart of the matter comes down to expectations. If we tell “average” developers that learning Ruby on Rails or test-driven development is too hard or only for smarter people, then we’re expecting (and in a way, encouraging) them to be mediocre. I expect a lot from the people I work with. I expect them to want to do the best job that they can, create well designed code, write tests, complete tasks quickly, and not write bugs. Is that realistic? Well, not exactly (we’re not perfect, so we will make mistakes), but there’s no point in striving for anything less than the best.

I also expect that if you’re in this business, you’re always going to be having to learn new things. Most developers are good at lots of different advanced concepts, like how to optimize SQL queries, how CSS works, how .NET garbage collection works, and things like that. At one point, these people didn’t know or understand these concepts, but they learned and now they’re pretty good at it. Most developers with 5 years of experience will be experts at something.

The real problem is when people do not want to learn. Like I said, I think almost all developers are capable of learning and understanding advanced programming concepts. People are always finding better ways to develop software, so I would expect that I’m always going to have to be learning these new ways so that I can be as productive as I can be. I think we need to encourage and reward learning.

When it comes to Ruby on Rails, I think that if you want to succeed at Ruby, you will need to write tests. In .NET you have the compiler, so people feel like they can not write tests and get by just fine, and to some extent this works (although I personally would not recommend it). In Ruby, you are much more likely to get burned by not writing tests. But if you can learn TDD and Ruby and become a much more productive developer and write better code, isn’t it worth the effort in the long run?

Now if you want to see a productivity hit, take a Ruby on Rails developer and have him do WebForms.

In a month or so, my co-worker and I will be wrapping up the project that we have been working on for the last 15 months. It’s a website for a company in the construction industry that bids on jobs and then tracks the progress of the jobs, purchase orders, billing, and everything else they need to run their business. We used ASP.NET MVC, Fluent NHibernate, AutoMapper, and SQL Server 2008.

We practiced test-driven development from day one. We wrote tests for our .NET code, tests for our JavaScript code, and tests for our SQL code. Right now we have over 14,000 tests, and I think we can break the 15,000 test barrier in the next month. I can run them all in about 5 minutes.

I cannot tell you how invaluable these tests have been. First of all, our application deals with money. The users will input a bunch of data about a job and then our application will tell them how much to bid on the job. We cannot afford to have bugs in our code that would miscalculate the amount to bid on a job, because that would lead either to over-bidding (in which case they would win very few) or underbidding (in which case they would win jobs and take a big hit). It just has to work.

Second, we did not have a QA team on this project, it was just the two of us developers. Frankly, I don’t have time to go back and manually test stuff in the app or regression test it when we need to make a change and deploy something. We do have bugs from time to time, but we haven’t had any critical bugs.

Because of our tests, we have been able to get as close to continuous deployment as I would feel comfortable with. On average, we deploy 2-3 times a week. When we go to do a deployment, I usually go through the site and manually test the new features that we are about to release. If I don’t find any problems, I run our deployment (which is all automated), and 5 minutes later, the changes have been deployed. I never go back and regression test old features or stuff in areas that we didn’t change.

Since the whole test and deploy process takes only about 15 minutes, users get their changes quickly. They don’t have to wait until later in the week, or until our next scheduled release. We have reduced the cost of change to pretty much just the time that it takes to code the changes.

All of this is possible because we were diligent about test-driven development and writing good unit tests for everything. The reason that we don’t spend time regression testing is that we don’t expect anything to be broken, and it very rarely ever is. This means that we can spend more time delivering business value and less time ensuring that we didn’t break something we wrote a year ago.

I’m not writing this to say how awesome we are as developers, because anyone can write tests and have the same kind of success. Also, we could’ve cheated and not written tests and ended up with potentially costly bugs and more time spent regression testing.

This is why I practice test-driven development. You end up with well-designed code, you drastically reduce bug counts, you can release more often, your codebase stays under control, and you have a lot less stress.

One of the commonly held principles of Agile is that you build software incrementally. I know a lot of you have heard this and think you understand what it means, but are you actually living it out?

Here’s what I mean: as a developer, when you say that a feature that you’re working on is done, are you sure that it meets all of the requirements? Have you accounted for all of the edge cases? Is it production ready code?

If you answered anything other than “yes” for any of those questions, then I would question what the word “done” means to you. “Done” does not mean that you’ve coded it to work in most situations and that you’ll rely on your QA team to find bugs for you to fix.

The problem is that when other people hear you say “done”, they will assume that you really mean done. This is especially true with business people and management. In their world, done means done.

There is really no point in not using the same definition of “done” as business people, because they’re the ones paying for your project. So when you come back to them and say that you need a few weeks to just fix bugs, they’re going to give you weird looks. “Wait, I thought you said that was done.”

Before you even start developing a feature, sit down with your BAs and QAs and define what “done” means for this particular feature. Think of all of the requirements, edge cases, and non-functional requirements (like how fast it should load).

Now you start coding. Write unit tests first that will prove that your code will fulfill the requirements. Then write the code to make the tests pass. Then go through the requirements and manually test it to make sure that you got it all right (you can’t easily write a test to see if you got your CSS right, or if the page loads fast enough). If you have to, refactor your code so that you don’t have any hacks or technical debt. Now you hand it off to your QA team. You should expect that your QA team will find no bugs in your code. Maybe they will find bugs (because you’re not perfect), but that will be the exception instead of the norm. You should think that your code is ready to go to production.

Now you can really say that your feature is done! My definition of “done” is that there is no more work to be done on the feature. That means that not only should it do everything that the requirements say, but there should not be any technical debt added or things that you have to go back and refactor later, because then you’re not really done.

So when you say you’re building software incrementally, make sure that you really are done before you move on. Have high standards! There’s no point in settling for anything less.