Outsourcing success tidbits

Last year we did a pretty cool “local O2O” (Online-to-Offline) project with a local TV station. The budget and timeframe were tight. And this project simply begged to be done with Ruby on Rails for a host of reasons.

We came in on-time, on-budget, with an exceptional end result after using elance.com to find a team in India.

Aside from insisting on and talking to references and seeing sample work, here’s a few tidbits we learned about making that work. To get a good bid (always go fixed-price) you have to have a good spec. Some keys include breaking the project into Phases, starting with a clear spec for Phase I, breaking that into at least 10 milestones. Some ingredients for a good spec are:

  • A full database schema. A fuzzy idea of the database, and/or turning the schema design over to anyone who’s not proven to be exceptional at it, is a train wreck. I repeatedly heard from good developers that a well-designed database lets them bid one-third to one-half of what it would cost otherwise. Take the money you’ll save and invest it in the schema design.
  • Mock up screens. You can not rely upon text, you have to show the fields, the buttons, etc. (It’ll help solidify your thinking, too.) Let me say this. The only three spots where we ran into ambiguity issues were the three places where we played a little loose on the sample screens, thinking it was “obvious” what those screens would look like.
  • Spec the environment. If it has to run on Heroku, make that clear.
  • Spec the unit tests. Contract developers in my experience do lousy job at this unless unambiguously required to do it right. And it’ll cost a lot less if part of the original bid than if you say later “oh hey, what about hitting X% unit test coverage.”
  • Include 2 or 3 major “gotchas”. Purposefully put at least 2 or 3 things into your spec that don’t make a lot of sense or contradict other elements of the spec. See who catches that. It’s instructive in picking a development team. As a trivial example, suppose part of your spec you’re going to run at Heroku. Put some aspect in your spec about storing files in some folder on the website. If they know their stuff they’ll immediately point out Heroku has no local file system, that you’ll probably want to push files over to S3. It’s a fair test IMO, because those sort of gotchas will happen anyway, so you’re entitled to ‘test’ developer’s ability to catch them before they spend you money writing code that won’t work.
  • Daily involvement. Generally, the closer you can come to full time co-involvement, the better the results. We setup a testing tag-team to test every feature as it was implemented, and actually designed the spec for incremental development and testing.
  • Spec comments and readability. I’m all about comments (lots) and code clarity (not using every cool shortcut the language offers, favoring understandability by humans over saving a few CPU cycles.) I provide examples of obtuse but fun little shortcuts that I don’t want to see, and the old fashioned way I do want to see it done instead. If I really wanted uber-dense tight code I’d go back to doing it all in APL or Forth. What I want is code anyone can look at and understand months from now.
  • Git / github. If you aren’t using it, do.
  • Daily code review. Review code as it’s checked in. Catch bad habits early.

Obviously that’s the tip of the iceberg, but those simple tidbits saves us a lot of time and hassle.