Read the Check-Ins

I recently enjoyed reading the following blog post by Joe Duffy:

Software Leadership #6: Read Every Checkin

I certainly do not want to submit a “me too” post, so allow me to simply add a few points.

During the days when I was helping to lead a larger software team, I also did my best to review every check-in notice. My reasons were generally along the following:

  • Following the check-in notices helped me keep an eye on the “pulse” or “attitude” of the team. Were the check-in descriptions submitted with a positive tone, or were descriptions along the lines of: “fixed another #!@%&* bug?” Is the entire team’s attitude positive, or are just a few members over-worked and stressed? Tracking and reviewing the check-in notices will help a software leader with such questions.
  • Are critical new features being implemented in a timely manner? Watching the check-in notices and reviewing progress is a great way to keep track of progress on assignments you might have defined but delegated for implementation.
  • Is the overall architecture and design being followed? If you see a check-in notice for “Implemented feature X”, but the files modified are in an unexpected area of the code base, then perhaps the engineer mis-understood the design requirements, or perhaps (gasp!) the architecture is not adequate and requires review?

There are many reasons to review and track the team’s overall check-in notices. As a software leader, I would agree with Joe Duffy: make it a part of your daily rhythm.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: