Recently we picked up a client that had a site developed by another Rails firm, and the project was not going well for them. The project was way behind schedule, and the site had lots of mysterious, unexplained errors. The previous developers had a fairly consistent answer to some of the basic tenets of Agile development, like testing: “We wait until the end to do all that stuff.” Documentation was an “extra” that needed ordering up-front. The entire development process was opaque to the client, leading to many sleepless nights filled with anxiety.

The tendency is to blame the original development firm. After all, they’re the ones jerking the client around, right?

Not entirely.

As a consumer of development services, its entirely incumbent on a client to do their homework and make sure that the person or firm they’re hiring is fully capable of delivering on what they promise. If you hire a firm filled with developers who are new to the Rails scene or who don’t take the time to stay current on their art, then you shouldn’t be terribly surprised when their work turns out to be sub-par. However, our client, like most people in their position, were not fully educated on what to look out for. There’s a a few good ways to tell whether you can trust the person or firm you’re hiring to deliver the product you want in the timeframe you’re asking for.

Experience

This is (or should be) somewhat obvious. Ask to see the developer’s portfolio, or to talk to some previous (hopefully satisfied) clients. The easiest way to know whether a shop is capable of delivering your website is to know whether they’ve done it before.

Testing

This is a core principle of Agile development. If the firm claims to have an agile methodology, whether they use Scrum or Agile or XP, then a test-first philosophy should be at their core. Ask them lots of questions on this one. What do they test with–Rspec? Cucumber? Test::Unit? Shoulda? A mish-mash of these, or some new framework? Great! Get specific. How large is the test suite on their last customer’s site? Dig deep. For example, if they’re using cucumber, ask how many steps the full suite runs. (For any but the most trivial site, this should be in the hundreds–for more complex sites, thousands.)

Open-source

Speaking of testing, how do we verify what a potential contractor tells us? One phenomenally great way of doing so is to see what kinds of open-source contributions they might have made, either as a firm or as an individual. This gives you the opportunity to see not only whether and how they test, but also what their code looks like. OSS authors also tend to stay current on the state of the industry and best-practices, both out of pride and necessity.

Bedside Manner

If you can't explain it simply, you don't understand it well enough.

**Albert Einstein**

How do they treat you? Does everything sound terrifically complicated and difficult to understand? If so, I’ve got bad news for you: either your contractor doesn’t fully understand what he’s doing, or he doesn’t want you to. Call it “Job Security.” This isn’t to say there aren’t things in web development that are complicated. There absolutely are, and you as a client have to understand that just because its a box on a web page that it doesn’t mean there aren’t some crazy magics going on back at the server to get it there. But if every single request is met with a long, convoluted explanation that makes your ears bleed by the time he’s done, then you need to find someone who is better able to communicate what he does for you.

Advice

This can be somewhat subjective, but one thing I think our clients appreciate when we work with them is that we get invested in a project, and as a result we’re not shy about offering advice about proposed features and changes. Clients always have the final say, of course, but when we see them going down a road we know from experience is fraught with peril, we’re not afraid to speak up.

This list is by no means exhaustive. Let us know your own experiences with selecting a contractor in the comments section!