Monday, December 29, 2008

RSpec: Cutting Edge vs. Fashion

Not long ago I was working at a corporation where most people weren't steeped in the Rails culture. Now I work for ENTP, and it's kind of like the Justice League of Rubyists.



OK, maybe not the Justice League. First, DHH is probably Superman, and DHH doesn't work for us. Second, the Justice League was always a little ridiculous. Maybe the X-Men of Rubyists.



Yes, that's us. We have gravity-defying breasts, waists as thin as our necks, and feet as long as our arms. OK whatever. I'm stretching the metaphor. I just wanted an awesome picture. Either way, the point I'm trying to make here: lots of people in ENTP know Ruby pretty well. Lots of prominent Rubyists.

The interesting contrast is that at this few-prominent-Rubyists corporation, people were like, "should I learn RSpec?" and "After I finish writing this code, I'm going to add some unit tests." At ENTP, people are like, "RSpec's too freaking big" and "after I finish writing this code, I'm going to release my own testing framework."

So at this corporation, people were asking me, "should I learn RSpec?" And I was really never sure what to tell them. On the one hand, RSpec doesn't feel as awesome as I would like it to. It's big enough that you could bludgeon someone to death with the code base if you printed it out. On the other hand, if you're not using TDD/BDD, you should start, and if you're going to start, starting with BDD will be a gentler learning curve than starting with TDD, because the terminology's clearer. I was very glad when I discovered Shoulda, because it allows you to get the terminology benefits of BDD with a much more lightweight framework.

The competition between testing frameworks is constant and intense. It's like if dinosaurs were still alive, and they rode into battle with soldiers on their backs manning laser cannons.



OK, it's not that intense, I just wanted an excuse for another great picture. But it is pretty intense. Complaining about your testing framework, or rewriting it, is so common that the only programmers who don't complain about their tests are the programmers who don't write any. If you ever want to screen out a non-TDD programmer during an interview process, and for some insane reason you can't just ask to see their tests, ask them if they have any complaints about testing frameworks. If they don't, then they don't use TDD or BDD at all.


(Slightly modified from the original. Stole the idea from Josh Susser.)

With so many options, an innocent question about which testing framework to use can turn into a really long conversation. I really haven't figured out what the guiding principle here should be. The question basically is this: how much of the productivity advantage RSpec users have enjoyed is due to using superior tools, and how much of it is due to simply being the type of people who seek out the superior tools, and then throw them away or redesign them? Because there are plenty of programmers who want to learn something and then not have to worry about learning anything new for at least six months. That's not how you get to the top of your profession, but it is how you enjoy a quiet life, and enjoying a quiet life is a reasonable goal.

The only certain conclusion I've come to: while enjoying a quiet life is a reasonable goal, it's not a goal I'm qualified to give people advice about. If you want to know how to spot a werewolf, how to find underground warehouse raves in foreign countries, how to survive a downhill highway spinout, how to avoid getting beaten up by gangbangers in the ghetto, or how to stay up to date with the latest and greatest Ruby projects, I can point you in the right direction. But there's a theme here. None of these things have much to do with enjoying a quiet life.



If you're not going to hack in your free time, fly to conferences, or even blog, should you learn RSpec? I honestly have no idea. I think the answer's yes, but I've noticed something about myself over the years. If the question is "should I buy this?" I will say "yes" for any value of "this" which you can use to make music. Likewise, if the question is "should I learn this?" and it's a technology that looks fun, I'll say "yes, you should." To me the question of "should I buy this music-making device?" comes down to "does it work?", and the question of "should I learn this technology?" comes down to "is it fun?"

But when a more cautious programmer asks that question, they're asking if it's going to be around more than a year. They're asking, "is this the next big thing?" It's pretty hard to answer that question correctly every time. Honestly I think the difference between learning the next big thing and experimenting with a whole bunch of different things is a difference purely of luck.

You never know what the next big thing is until the dust has settled and the winner's been decided. If you wait that long, you're not learning the next big thing; you're just learning the big thing. The only surefire way to learn the next big thing every time is to learn every damn thing there is. It's impossible to predict which experiments will succeed. That's the whole point of experiments in the first place.



And that's my excuse for not learning Merb. Oops!