We’ve been working with and on Rails for the past four and half years here at 37signals. The sum of those efforts just got a new label today: Rails 2.0.

It contains a ton of good stuff. Lots of things regarding our love of all things HTTP. The RESTful angle. Multiviews. Security improvements. Lots of speed tweaks.

It’s been a joy extracting all these features from their origins in Highrise, Basecamp, and the rest of our applications. Deriving frameworks from production code really is a pleasant way of arriving at something useful.

Come January, Jeffrey Hardy will be joining the team here at 37signals. He’ll be working alongside Jeremy, Jamis, Sam, and myself on the programming side of things. We’re terribly excited to get him on board.

This also marks the return of the multi-country workforce label that we lost when I moved from Denmark a few years back. Jeffrey is from Toronto, Canada.

Jeffrey blogs at Quoted-Printable and is a co-author of Beginning Rails. Say hi to Jeffrey everyone.

Most of the time you should be working on The Next Most Important Thing. Whatever that is, large or small. But there are times when it’s okay to depart. Times when you need to depressurize after completing a dive in the stressful, complex pool of Big Problems. Nobody can stand to be all fire, all the time.

So think about layering your priorities accordingly. Don’t schedule one Herculean task after another and leave all the coasters for the end. Sprinkle some of the easy stuff like pit stops over the course.

It’ll give you a time to breathe and to make progress without wringing out every drop of smarty smarts from your overcooked brain.

Programmers are usually inherently logical people. We get the job done by breaking down big problems into small chunks that we can wrap our heads around. This gives us a feeling of being in control and in command of our environment. I think that feeling is a large part of why programmers enjoy what they do. But our reliance on this sense of control is also exactly why we can become so distraught when we lose even a sliver of that control.

Panic gives rise to supernatural self-pity
And losing control is mostly associated with the onset of bugs. Those pesky little critters that we infuse with a sense of drive and intent when we can’t pin them down. They’re out to get us, aren’t they? They’re like hobgoblins lurking under the bed, just waiting for us to doze off and then they’ll take over the room. Only the room is your mind and when they do take over, panic turns it straight to mush.

This panic usually manifests itself as self-pity: Why me? Why now? Why can’t this just work? Those are the questions of capitulators, someone who has given up on logic and succumbed to the supernatural belief that the universe is out to get him. Hogwash, of course, but extremely common none the less.

Bugs are always about a lack of good information
What keeps the panic coming back is that programmers fail to internalize the outcome of every single bug they’ve encountered in the past. There were never any hobgoblins, there was always a logical explanation, and it was usually just a lack of good information. You didn’t think that A would result in Y, but was convinced it was Z.

But somehow this fails to seep in unless you make an explicit point about it. So please do that. The next time you think something is bizarre or impossible, remind yourself that it is not. That the universe is way too busy to concern itself with mocking you. You’re just not that special. Then roll up your sleeves and find that bit of missing information that’s causing things to work counter to how you’d like or expect.

I’m curious what software test methodologies and tools you use. Are you religious about Test Driven Development (TDD)? Do you use Rails’ Test::Unit, or do you prefer alternate tools such as Behavior Driven Development with rspec? A list of the test-related plugins you use would be interesting to see.

We’re big believers in the benefits of testing, but I wouldn’t call it religious. I personally rarely get into the flow of writing my tests first, except for transformation-style methods that takes known A and turns it into known B. I find that test-first often doesn’t fit my brain all that great for molding beautiful APIs. I know, though, that it works wonders for others and I deeply respect that approach. On our team, it seems to work especially well for Jamis at times.

I’m perhaps also a little on the fringe in regards to how much I test. I don’t believe that getting 100% coverage is worth it in most cases. Especially not when it comes to testing view code. For our applications, it simply changes too often and the criticality of display bugs is low and very rarely realized anyway.

The areas of testing where I personally derive the most benefit is from object-interaction tests. Like testing the signup form that creates a handful of records at once and need to spread error checking across the lot. Or dealing with project limits in Basecamp that’ll interrogate multiple other classes. Or API interactions for the creation of Writeboards.

For people new to testing, though, I would recommend going all-out from the start. The only way to get a good grasp on when you can be more lax in your testing is to have done “too much” for a while and identified areas that could go with less without materially hurting your productivity now and in the future. So in that sense, easing your testing rigor is a late-stage optimization that needs to be done with great care. If you’re ever in doubt whether to spend time testing or not, test.

In terms of tooling, we’re using the vanilla Test::Unit flavor that ships with Rails. I’m personally not convinced that rspec holds much improvement over it and I tend to think the DSL-style has been taken a tad too far. But I do like the BDD-style focus of naming your tests in terms of “should” and I use that in my own style. In the large scheme of things, it really doesn’t matter one way or another. The important thing is that you test and if rspec and BDD makes testing more enjoyable for you, rock on.

Also, while I don’t think striving for 100% test coverage is worth it in most cases, it’s nice to know where you stand none the less. The rcov package provides a great way of seeing how you tests are holding up and where you might be lacking.

Gary asks a follow-up question to How has open source helped or hindered?:

Why do you use Mac OS X as your laptop/desktop/development machines OS instead of a Linux distro?

There is really nothing religious about our use of open source. We use it because it’s better on the scales of merit that we care about. For infrastructure software, such as web servers, databases, server operating systems, programming languages, and web frameworks, the scales of merit lend themselves incredibly well to open-source development. Thus, we use it and are passionate about it.

For desktop operating systems? Not so much. There are just too many disciplines involved that programmers are not naturally good at and don’t have sufficient levels of taste to prepare masterfully. And programmers constitute the vast majority of builders in the open source community.

So it’s not unreasonable to think that these programmers will do exceptionally well when they’re designing for them and their kind, but at the same time do less well when they’re trying to figure out what makes a great iPhoto or iTunes or what have you.

Therefore I tend to think that open source is at a natural disadvantage at creating end-user applications, in which I include OS X and Linux destined for the desktop. It’s not impossible, just very hard.

Firefox is always heralded as a great example of good end-user software, but I do think that in part is because they’re mostly just doing great infrastructure advances (spec compliance, developer tools, security) in a familiar shell (how much difference is there between Firefox and the early browsers on the UI?).

Which interestingly enough is also how my usage of Firefox goes. I use it for development purposes (primarily because of the developer plugins, like Live HTTP Headers and Firebug) and I use Safari for recreational purposes.

So what I’m trying to say is that for me, OS X is just better on the scales of merit that I care about when it comes to an operating system that needs to be so generally applicable as to deal with my email, IM, browsing, music, pictures, productivity apps, and more.

In other words, I’ll stick to OS X on my Macbook Pro (tight integration between hardware, software, and services is the hallmark of OS X’s superiority), but be equally thrilled to use Linux and FreeBSD on the server.

It’s incredibly tempting to create a road map when you’re driving a software product. You get to reap the glory of announcing desired features without even a downpayment of work. It takes no design, no consideration, or even discipline to respond to feature requests by making them a bullet point on a road map. It’s like buying goodwill on credit, but what you don’t pay for now, you’ll pay for later with interest.

Like functional specs earlier in the development phase, product road maps are fraught with trouble. The due diligence process is usually twice as shallow, which means that you’ll inevitably end up promoting illusions of agreement. When all we have to agree on is a slogan, like “Meetings Tab, 4th Quarter”, it becomes an empty imagination box that’ll fit wildly different expectations. Disappointment, however, is sure to ensue when only one set of expectations can actually be met.

Even worse than mismatched expectations, though, is the slippery slope of selling tomorrow over today. When you sell the software that you actually have, there’s a limited amount of wriggle room to cajole prospects. Customers has to make real decisions about whether the current state of your software is a good fit for them. Some times it’s not. That’s okay.

It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see.

If your software is not really a good fit, it’s very easy for customers to convince themselves that it will be, if you greet them with an illusion of agreement over a few “deal breakers”. But when you finally do deliver, you’ll also burst that illusion and end up with disillusioned customers who thinks you suckered them into buying a cow and then gave them a goat.

And worse, while it might seem free at first to win customers by promising them gold at the end of the road map rainbow, it’s not. Accepting new entries to the product road map carries very real development debt. This debt will shrink your degrees of freedom. Your ability to pursue new great ideas as they arise will be seriously dampened when you’ve already committed to a tall stack of requests eagerly awaiting implementation.

Builders bound by the guesswork of yesterday are not going to be happy troopers. It’s demoralizing to be forced to work on something not because it’s the right thing to do at the time, but merely because the promise note is up.

But try avade and you’ll soon hope that it was merely your mob-connected bookie you were trying to dodge. Customers do not forget your promises — especially not the ones that were won over specifically because of the promises of a road map.

Ross asks:

37signals has contributed massively to the open source community, but in what ways has the open sourcing helped and hindered 37signals and would you advocate that more companies contributed or open sourced their software, if so what advice would you give them?

Open source provides an incredible amount of technical leverage for small companies. No matter who productive your rock-star programmers are and no matter how much judo you apply to your problems, solid infrastructure takes a long time and benefits immensely from broad involvement. It really does take a village to raise great infrastructure.

The Ruby on Rails framework of today is a lot more productive than the one I was using before it was open sourced. I use features every day created by others, enjoy polish done by others, evade bugs caught by others. All work I would otherwise have to do myself. So I simply get more done for less effort than it would otherwise have taken. The same holds true for the other open source projects that have been cultivated in 37signals, like Prototype and Capistrano.

Getting more done for less is the obvious benefit of open sourcing your work. But there are a lot of other positives as well. For one, it feels good to give back. 37signals as a company is possible in part only because of how open source lowered the barriers of entry for small businesses.

Everything from the operating system to the database to the web server to the proxy engine to everything in between on our servers is open source. If we’d have to go back to a time where all that carried big upfront licensing costs, we might never have gotten the product direction for the company off the ground. Helping further that ecosystem is very rewarding.

It also gives you a public arena to learn from other great programmers and to better yourself. Most of the people using Rails are working on proprietary applications, so we don’t get to share or discuss the specifics of the projects all that often. But we do get to share and discuss the specifics of the infrastructure. That’s the best continued training course you could ever run.

Through that public arena you get access to scout for the best minds and hire people of exceptional talent. We have found all our current programmers through the Rails scene and had access to evaluate much of their work as a result of open source. I also wrote about a few years back.

Sprinkle on top that if you happen to run a successful open-source project, you’ll probably attract a fair amount of press attention and customer goodwill. 37signals has definitely benefitted from both of those categories off the many open source projects that we run.

So you get all these positives, but what about the negatives? I really don’t see any. A big fear that a lot of people have is that they’ll somehow be giving away their secret sauce. Unless your actual product is what you’re open sourcing, it really doesn’t matter (and there are even plenty of examples of that working well). It’s unlikely that the piece of code that’s only seen internal development is such a silver bullet that you’re going to outshine your competition by its use alone.

All that to say that I think open sourcing infrastructure software is a great idea. I’d heartily recommend it to anyone sitting on a piece of code that more people could benefit from and that they’d like to see developed further.

In Kitchen Nightmares, Gordon Ramsay does make-overs on failing restaurants and turns them into respectable enterprises through a combination of cuisine guidance, managerial pruning, and loads of swearing when things fail to meet his standards.

It’s a fantastic show that gives grim insight to the scary state of affairs of the chosen spots, but it also goes beyond the schadenfreude and saves these places from going out of business.

What makes Ramsay’s approach to restaurant revamping so interesting, though, is how applicable it feels to software design. The characteristics of a failing eatery ring remarkably similar to those of a poorly-run software product:

Everything to no one
Almost all Ramsay’s cases feature an overstuffed menu derived from a misguided notion that more choice is always better and that making every dish under the sun will broaden the appeal of the restaurant. The first order for the cuisine is to trim the choices and go from thirty-some dishes to ten or twelve.

Compare this to a piece of software overflowing with features. None of them particularly tasty, none of them particularly well done, all of them burdening the user with a learning curve and all of them cluttering the interface to the point of mediocracy.

You don’t tickle patron’s taste buds by all the dishes you can make that they don’t eat and you don’t delight users by spreading yourself thin over all the features they won’t use.

Cook what you know
British chefs slicing Japanese Sushi or Indian chefs cooking traditional American cuisine are two examples that Ramsay cracked down on under the banner of Cook What You Know. If you don’t have a strong history of eating and living with certain ingredients and styles of cuisine, it’s much, much harder to reach the upper echelon’s of taste. And why bother? Pick your native ingredients, those in season, and make what you know and can personally appreciate.

The same is true for software. When you create products for yourself, you’ll have a much easier job and most likely be much better at it too. It’s hard to make good food if you don’t know what excellence should taste like and it’s equally hard to craft good software if you can’t appreciate what brilliance looks like.

Passion for your environment
Great chefs care about their tools and their environment. Poor chefs let their kitchens go and don’t cleanup the messes they create. In the world of food that’s not just sloppy, but dangerous as well. One of Ramsay’s common shocks come in the form of “I fucking ate this!!” when he looks at the ingredients and machinery that produced his welcoming meal.

Great programmers are like great chefs. They care about having a clean, productive environment. They surround themselves with beautiful code that they craft with tools that they enjoy. You can’t disregard your tools and think that you can still produce great work. It doesn’t work in cooking and it doesn’t work in programming.

That’s just a small taste of the similarities. Ramsay has plenty of additional lessons to teach software creators about vision, simplicity, and executing on the basics beautifully. I highly recommend setting your DVR to pick up the American version of Kitchen Nightmares on Fox every Wednesday from 8pm. The original British ones from BBC are great as well.

We’re looking to add another person to the team. Interested? See our job ad for more details.