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.

If there’s one constant in software development, it is change. Our entire workday is spent changing things and responding to change.

Every time you write a line of code, you are changing it. You might add new features, fix bugs, or make changes to existing code. However you put it, you’ll be changing the code.

Requirements will change. You often find this out after you’ve coded a feature, and now the business either changes their mind or you find out that you made some wrong assumptions.

Business priorities will change. What was important yesterday may not be important today, and six months from now, all kinds of things might change. There could be new, more important projects on the horizon, new people in charge, or new business opportunities.

Software development teams change too. You might stay at your company for many years, but during that time, you might get moved from project to project. Developers will leave the company, and others will join. The end result is that many different people will end up working on the code that you’re writing today.

Since we know that we are going to have a lot of change, it would therefore make sense to reduce the cost of change so that we can respond to change as quickly and easily as possible. So how can we reduce the cost of change?

Automated Testing

Every time I add a line of code, I risk breaking my application. Breaking the application is just not acceptable. We’ve come to accept bugs as a part of the process, but that doesn’t mean that it’s OK to write bugs. If you’re not striving to write bug-free code, then maybe you need to raise your standards.

Nevertheless, the fact is that we all screw up and we all have the capability to create bugs. Knowing that, I want a way that I can easily test my application so that I can ensure that I find out if I broke something once I change it.

On my current project, I’m writing an application that helps my client bid on construction projects. They can’t afford to have bugs in their system that will cause them to incorrectly bid on these jobs or they could be out a lot of money. The bottom line is that it has to work because their entire business is now running on the application that I’m writing. They also come to me on a regular basis with new feature requests and things they need changed. They don’t want to wait months to get this functionality, and they also don’t want me to break any existing code.

Thankfully I have a large suite of automated tests that I can run to ensure that I didn’t break anything. This isn’t foolproof and things sneak through, but it’s usually little stuff that isn’t critical. But it’s good enough proof for me that I didn’t break the existing functionality. As a result, I can release to production daily and I spend virtually no time manually regression testing my application when I deploy. My unit test suite has reduced my cost of change to pretty much just the time it takes me to code the changes, so now I can react quickly to changes, release all the time, and I can do it without breaking existing code.

Clean Code

Sometimes people will write their unit tests, write the code to make the tests pass, and then assume that that is good enough. That’s great that you wrote tests, but how easy is it for someone to make a change in your code?

I feel that clean, readable code is very underrated these days. When you write code, are you thinking of the person that is going to need to understand what you did once you’re not around anymore? That scenario is very likely to play out at some point. So when you write code, create methods, variables, and classes that are very descriptive. Place a priority in making your code easy for someone else to read.

“Clever code” is the opposite of clean code. I’m talking about using complex algorithms to solve simple problems, trying to using a complicated LINQ statement to do an operation that would be more readable in a foreach loop, or trying to implement something in the fewest lines of code as possible. There are times where you might want to do things like this, but usually it’s more important to write code that is easier for someone else to read and understand. Again, remember that someday someone else is going to have to change your code, so write descriptive code that makes it easier for that other someone to know what to do.

Tests Are Documentation

Your unit tests are documentation of what your code is supposed to do. I practice behavior driven development, which means that my unit test methods describe some business functionality that my code is in charge of executing. This way, if someone needs to know what my code does, they can look at the test classes and methods and see what it is supposed to do.

Lately I’ve started adding a lot more comments in my test methods. The class names and methods names may describe what the code is supposed to do, but it doesn’t always explain why. I’ve found that sometimes it helps to write down the why because that is also important information. Since people can look at my tests as documentation of what my code does, I figured that this would be the best place to put the whys, because if someone has to change my tests, they’ll immediately know why I did what I did and they’ll have a reminder that they need to update my comment.

Build Iteratively

Since business priorities and requirements are going to change, we want to reduce the cost of this change too. If the business comes to you and drastically changes the requirements or certain assumptions that you might’ve made, it might be really costly and painful to change, and you can only do so much about that. What we can do is make sure that we’re constantly checking back with the business to see what they want now so that we have as few surprises and as little rework as possible.

This is one reason why Agile projects often run on iterations. As a part of this process, meet with your business sponsor every week or two and talk about what you’re going to do next. Show them what you’ve done in the last week or two, and make sure you’re on the right track. This way, if they’re going to change their minds, you’re giving them permission to do so and you can adjust what you’re doing as soon as possible so that you have the least amount of rework.

Always Be Aware of Change

Quit thinking short-term and quit shoving code in just to get it done as fast as you can. You may think you’ve done something good by getting it done faster, but if you create more work and pain in the future, it’s a net loss. Instead, always think about what the effects of what you are doing now will be two years from now. Your goal is to create business value without creating technical debt. A home builder can do shoddy construction and put nice looking paint and siding on the house, but 10 years from now when the problems arise, people won’t be thinking very highly of that builder. Don’t make the same mistake. Take pride in your work and strive to always leave your code base cleaner than you found it.

Here are the slides from my Productivity Boosters talk. Some other links you might be interested in:

• Visual Studio 2010 Keyboard Shortcuts
• Visual Studio 2008 Keyboard Shortcuts
• ReSharper
• ReSharper keyboard shortcuts
• AutoHotKey
• CLCL (clipboard manager)
• AgileZen

Create a plan of how you are going to be a productive and effective developer!

I’m doing a quick little “grok talk” at the CONDG meeting this Thursday, July 22. I’ll be talking about some simple productivity tips that have helped me to get things done faster and become more productive and effective. While this does not sound very exciting and sexy as hearing Tim Wingfield talk about IronRuby, finding ways to become faster and more productive is something that we all could use.

And if I end up boring you to death (which I don’t plan on doing), you can stay and listen to Tim talk about IronRuby.

When you go to work and write code, you have one main tool that you use – your dev machine. The power of your machine will partially determine how fast you can get things done.

How often does your company buy you a new machine? Every 2 years? Every 3 years?

I don’t know many companies where developers get new machines every 2 years or less. I’m here to show you why waiting longer than this makes no sense.

It makes no sense because hardware is cheap, but developers are expensive. I’m currently on a project where I’m working on dev machines that were purchased in early 2008. I’ve worked on other projects with machines that were 6 months old that were considerably faster.

On my project, it takes about 45 seconds to compile the solution. But what if I could reduce that to 40 seconds per compile by buying a brand new top-of-the-line machine?

Let’s say that I compile every 5 minutes. So in an 8 hour day, I compile 96 times. Each day, I will save 480 seconds, or 8 minutes. If I work 1900 hours in a year (which equates to about 11 months of work days since most people have about one month of work days in PTO), I will save 1900 minutes, or 31.6 hours.

Let’s say that the average developer on your team makes $75,000 a year. If that were the case and you worked 1900 hours, you are making $39.47/hr. This means that if you save 31.6 hours of this developer’s time, you are essentially saving $1250 over the course of the year.

For $1250, I can buy a pretty good dev machine, especially if I don’t buy monitors to go with it and use existing monitors. I think I used pretty conservative numbers here too:

• I think I could probably cut compile time by more than 5 seconds by replacing a 2-year-old machine with a new one.
• I probably compile more than every 5 minutes (especially when I’m making failing tests pass or making little changes in the app and running the app to see if it worked).
• I only looked at compile time — I didn’t look at how long it takes for a machine to run tests, how long it takes to run long-running database queries, or how long it takes for your app to start up.
• I didn’t account for the productivity hit developers take because they switch their focus on to something else for 45 seconds while they wait for the solution to compile.
• Some developers make more than $75,000, and if you’re dealing with consultants, you have higher hourly rates.
• Many developers work more than 1900 hours a year.
• I didn’t take into account the feeling your developers get when you reward them with shiny new hardware, which will make them feel like you really care about them.

Even with my conservative estimates, I would say it is definitely worth it to buy new machines at least every 2 years. You might even be able to argue that you should buy machines every year. You would have to do the math and see if it’s worth it.

Convincing IT managers to go for this is difficult for some reason, even when you show them the numbers. So many IT managers will tell you that spending is frozen, or that they don’t have money in the budget for hardware, or that it’s not fair to buy the dev team new machines but not buy <insert team that doesn’t really need it> new machines. Are you serious? You would rather have your developers, who are expensive relative to the cost of hardware, have to sit and wait longer for the solution to compile? This is short-sighted thinking. You’re pretty much guaranteed some level of return on that investment within a year.

If you’re going to hold your developers to a high standard, empower them to meet these expectations and make sure that you’re giving them the best tools available.

I had a simple problem today. I had to turn this:

… into this:

[TestFixture]
public class When_depositing_money_into_an_account : Specification
{
    [Test]
    public void should_add_the_specified_amount_into_the_account()
    {

    }
}

[TestFixture]
public class When_withdrawing_money_from_an_account : Specification
{
    [Test]
    public void should_withdraw_the_specified_amount_from_the_account()
    {

    }

    [Test]
    public void should_specify_that_the_withdrawal_was_successful()
    {

    }
}

I really didn’t want to do all of this typing every time, so I wrote code to do it for me. It works like this:

1) Copy the acceptance criteria text onto the clipboard
2) Run Specs2Tests.exe (will put the code onto the clipboard for you)
3) Paste the code into your code file

Now I can get all of my acceptance criteria nailed down in a text file where I don’t have the ceremony of a programming language, then let something convert them into tests. Since I just cranked this out today, I’m guessing that it doesn’t handle every scenario that you might think of, and it only writes out C# code. There is no reason that it couldn’t spit out VB.NET, RSpec, or anything else. If it doesn’t do what you want, get on github, create a fork, and send me a patch!

The code is here: http://github.com/jonkruger/specs2tests. Have fun.

During the last week I was able to go to two software development conferences, the Ann Arbor Day of .NET and Stir Trek. I love these events because I get to see a lot of people that I don’t get to see on a regular basis.

On the other hand, I don’t feel like I get much out of the sessions anymore. It’s not that the sessions are bad, but I feel like I’ve heard a 100/200 level talk on pretty much everything I want to hear about. At each of these conferences there have been some talks that I have really enjoyed, but a lot that I don’t have a real interest in hearing again.

Granted, I’ve been to more of these events than a lot of people. I remember the first time I went to events like this and they were awesome. I was learning a ton of stuff and it was new and exciting.

I miss that feeling. I certainly don’t know it all. I know there is a lot that I could learn. But I guess I’m ready for a new kind of conference. Some ideas floating around in my head:

• A conference featuring mostly 300-400 level talks
• A BarCamp style event where anyone can sign up and show code
• An all open space conference

I know there are conferences like this. I know I’m not the only person who thinks this because I’ve talked to other people feeling the same way. I’ve heard of some of these conferences, but they’ve been other places other than Central Ohio. For example, look at the session list for the most recent ALT.NET Seattle event and notice the difference between this event and the various Day of .NET events. Granted, the target audience is different. But I’m a part of that target audience. I don’t always have the time and money to travel to these events.

I think part of the problem is the wide breadth of technologies in the .NET space. In the last year Microsoft has released Silverlight 4, Windows Mobile 7, .NET 4, ASP.NET MVC 2, OData, and probably other stuff that I can’t remember off the top of my head. So it’s really easy to come up with an “Intro to <insert new MS tech here>” because there are so many choices. Often times these are compelling topics, don’t get me wrong. But every day I go to work and I’m working on plain old web apps or Winforms apps or WPF apps like the rest of you. I want someone to come talk about how I can do better at what I’m doing every day. Show me how to better implement design patterns, or how to test my code better, or how you structure your MVC app to take advantage of jQuery validation, or how to use some ORM, etc. Those things will help me do a better job on the projects that I’m working on today. Sure, I’m curious about Windows Mobile 7 and Silverlight and OData, but my first priority is to get better at the stuff I’m using at work right now.

I feel like I’m getting a lot of talks that might pique my curiosity about new technology, but not a whole lot about how I can improve at the stuff I already know. I’m talking about talks like Nate Kohari’s talk at MIX about how he built Agile Zen with ASP.NET MVC and jQuery. When I watched this talk, I got some ideas on how to do some things, but I also realized that Nate is doing some crazy stuff with jQuery and JavaScript that I would’ve never thought of. It showed me some things that I need to go learn that could really help me on my current ASP.NET MVC project.

Please don’t think I’m criticizing conferences like Stir Trek or the Ann Arbor Day of .NET, because they’re good events put on by volunteers who spend their own time to put it on without any compensation, and I’m really thankful that people spend their time so that we can have community events like this.

I guess I’m just looking how I can take my daily work to the next level.