Ted Driven Development

Earlier this year, I was helping an old friend weed-out candidates for his latest Ruby on Rails venture, adPickles, and in the interest of cutting to the chase and letting the potential hires know what they were getting themselves in to, I sent them the following manifesto:

I just wanted to drop you a note to give you a little heads-up on the way they run development teams, so you can comment, inquire, or run screaming for the hills :-)

* TDD

First of all, they're a huge proponent of Test Driven Development (TDD). They aren't always faithful, but they enforce it as much as they can, and when you see the code that has been written so far, you'll see that there's a veritable butt-load of tests.

They haven't yet incorporated any sort of test coverage metric, but they do rely on autotest, which re-runs all of the appropriate tests every time they change a line of code. This tool is invaluable for catching all those "oops I didn't expect this to break that" moments.

If you commit code to the repository that fails a test, your humiliation will be merciless :-)

* DDT

Likewise they are adamant about Defect Driven Testing (DDT). Whenever the Big Boss Man shoots a developer an e-mail saying "hey I think I found a bug" the first thing the developer does is write a test to reproduce the issue. That test becomes a permanent part of the application test suite so that particular bug will never again sneak back into the application without unnoticed. They will expect you to do the same every time you are asked to fix or change something.

* Branching

If you don't know how to handle branching in Subversion, now is the time to figure it out :-)

Every time they take on a new developer, they insist that the new hire perform all of his development in branches rather than directly in trunk, until such time as they trust them to interact directly with trunk, or until the team grows so big that working directly with trunk is simply taboo and they all work in branches. This ensures the purity of the code base.

* Commits

One commit per change. If you have three items on your TODO list, you do one then commit, then another and commit, then the last and commit. You don't do all three at once and commit one big chunk of changes. Why? Code reviews...

* Code Reviews

They use Trac for code reviews. If you've every poked around the Rails core site you've seen this tool. The changeset feature gives them a nice purty color-coded "diff" of every change you made for each commit. This is why they insist on one change per commit. This allows them to review your work on a clean per-ticket basis. Your work will not be merged back into trunk until they have code reviewed and approved it.

* Referential Integrity

Just a side note here. I believe in foreign keys. If you've dug deep enough in my blog you'll see that DHH and I disagree on this issue, and if you saw/heard the keynotes from RailsConf last year [ED: referring to RailsConf 2006 in Chicago] you'll know that I'm not alone in my disagreement. This project has referential integrity in the database, which they achieve through a plug-in. You'll see this if/when you come on board. [ED: I later changed my stripes on the matter, during RailsConf 2007 in Portland as a matter of fact.]

* Deployment

They use Capistrano for deployment, and for now only the lead developer performs deployments.

When you finish up some work and it needs to be reviewed by the president, you'll let the lead developer know (through Trac). He will then code review it and (if he approves it) merge it into trunk. He will then deploy from trunk.


That's the basic gist of it. If you have any questions, comments, or concerns, please let me know. Thanks for your time.