Skip to content

Developers: frantic to free in 6 easy steps (part 2)

2010 November 8
by John

This is part of a series of posts chronicling my team’s adventure in making release day suck less.

Note: I would highly recommend giving each of these a shot in a way that fits your team. I would also recommend trying to implement each one at a time. If you spend time focused on each step, tweaking where there’s pain and adjusting to your team’s personality you’ll find everyone owning the end result. You’ll also show them you don’t know everything and need their help figuring some of these things out, which actually helps build a stronger team.

Here’s what we did, pretty much in the order in which we added them to our process:

  1. Unit testing
  2. Code review
  3. Continuous integration
  4. Daily stand up
  5. Iterative requirements gathering
  6. Lightweight develop/test/release process

Code Review

There are several ways to go about this, each with their own set of pros and cons. We evaluated our development style as a team and decided to go with a FULL TEAM peer code review every week. We all sit down in a room with a large screen and diff (almost) every file of every change set made since last review. With a team of four, it takes about 4 hours a week.

What this gains us is a common time to look at new things another person on the team is doing or trying out, learn and make comments. It also brought us all to a common development style, which makes it easier for others to help pick up the slack if someone gets behind. We also evaluate our UI as part of this, which has helped us maintain a common metaphor across the application, even though each developer has their own area of expertise. While our areas are mostly distinct and project may or may not cross those boundaries, our styles, enhancements, pitfalls, and UI adjustments all do.

Yes, four hours a week for a team of four is a big time commitment. Yes, we still miss things. Yes I sometimes buy lunch for everyone to clear the glaze from everyone’s eyes. But yes, it’s definitely worth it. I myself have been caught taking shortcuts and my team has held me accountable to either fix it before the release, or schedule a follow task to fix it soon.

We’ve toyed with the idea of one-on-one code review, but that accomplishes something different than what our team actually needs. It would provide a deeper dive into test cases and system stability, but we decided to rely heavily on our unit testing for that. And since we have so many different projects going on at the same time across so many functional units within the company, this is a great way to keep our team feeling like a team.

You will need to experiment with ways to keep it fun though. Our build breaker has to wear a very distinct shirt on code review day that others in the company have started to look for. We keep the tone light as much as possible, and as I said before I buy lunch from time to time. Food goes a long way to keeping people attentive during that long a meeting.

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS