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.