I published a quote the other day, but didn’t really elaborate as to why I thought it was good.

I’m really bad at remembering a long series of repetitive steps.  When building software, there’s a whole pile of things going on, and inevitably some of the necessary steps will get missed.  At VendAsta, everyone’s committed to building high-quality software, and part of that involves crossing all the Ts and dotting all the Is.  To facilitate this, we ruthlessly automate as much of the tedious, repetitive steps of building software.  Here’s a few things that come to mind:

  • Fixing bugs without having them logged in our Issue Tracker (Jira). I’m notoriously bad for seeing a small bug and just fixing it.  We address this in two ways: first, you can’t make a check-in into Subversion without putting an issue number in the comment; and second, when we do code reviews, the reviewer is definitely going to comment on changes that are happening to unrelated files.
  • Committing changes without running the unit test suite. As soon as you do a commit, our Continuous Integration server (TeamCity) does a checkout and runs the unit test suite.  If you’ve broken anything, you get an email and feel shame for forgetting.
  • Committing changes without writing new unit tests. TeamCity handles this too!  As soon as you do a commit, TeamCity runs unit test code coverage on it and produces a coverage report.  We review this periodically, and if there’s code that doesn’t have test coverage, we spend the time to fix that.
  • Making a commit, but not leaving a comment on the associated issue. We’ve got a commit hook for Subversion that automatically puts a commit log on the issue associated with a commit.
  • Missing a step when building the software. There’s a few steps to building our software (it’s not that complicated, but missing a step could result in weird deployment problems).  We use Ant to automate the build.
  • Screwing up the deployment process (or forgetting). There’s three different places we can deploy too: local development server, Google App Engine (demo/staging site), Google App Engine (live product site).  We want the local development server to always have the latest version of trunk, and we selectively push revisions up to GAE.  All of this is automated with the CI server.  On commit, we do a build and push it to the local server, and we’ve got two manual CI targets to deploy to the different GAE apps.

All of this (and I’m sure I missed other automated tasks) means that we can spend more time thinking about developing software, and less time worry about tedious things we might have forgotten.