Code Climate, the purveyors of software services that help engineering teams become more efficient and productive, recently held their second annual Code Climate Summit. In the opening keynote, Bryan Helmkamp, CodeClimate CEO, outlined 7 conclusions he’s made about how to improve the efficiency of software development teams, using data gathered from hundreds of users of their Velocity metrics product.
Pushing code Quickly
- Moving fast does not mean breaking things. Comparing the time from first commit to PR merge with the frequency of reverting commits, Bryan was unable to find any correlation. This indicates that, contrary to what one might intuit, developing and merging quickly does not necessarily introduce breaking changes.
- Encourage pushing code frequently. Developers who push code more frequently are more likely to have their pull requests merged. When pull requests languish for a while before merging, the likelihood that they will ever be merge decreases exponentially. Pushing less than 3 times per day is concerning but 5+ is great.
- Create uninterrupted blocks of time to code. One surprising metric was that the average developer does not even commit code 5 days a week. Rather, he or she commits code 3 to 4 days per week. Teams should aim to have every developer commit code at least 4 or 5 days per week and they can achieve that by scheduling uninterrupted coding time.
Reviewing and merging efficiently
- Aim for fewer than two review cycles per pull request. Code Climate defines a review cycles as a push of code, followed by a review. Teams that deliver more pull requests generally have two or less review cycles per pull request. This conclusion is logical. If you write code that is reviewed and then edited again many times, it’s more likely that code has some major issue.
- Pull requests that are opened earlier merge faster. When you open a PR quickly after committing, you can merge it faster. This also points to the benefits of small, atomic pull requests. If you can break a feature down into a smaller unit of work, you can be review and merge it quickly.
- Open pull requests within one day of the first commit. Bryan recommend opening PRs within one day of the first commit. Building on the data that PRs opened earlier merge faster, Bryan recommended aiming for one day or less from initial commit to PR opening.
- Review code as quickly as possible. Pull requests that sit unreviewed for a long time are more likely to become one of the dreaded “abandoned” PRs: closed and never merged, lost to the bit bucket forever.
Bryan concluded his keynote with a statement that rings to true. “The happiest developers work on the most productive teams.” The most productive teams I have worked on have been the most satisfying. (Even when those have been lower on the Pyramid of Satisfaction.)
The happiest developers work on the most productive teams.
As a tiny engineering team, we can still keep these metrics in mind as part of our development process. The most important of these recommendations is to try to increase the number of days each week that I commit code. That means ensuring that I set aside time for Nimble Industries work every day. It’s also heartening to know that moving fast, committing fast, and merging fast, doesn’t break things. Instead, these are all essential qualities of effective software engineering teams. Even a team of two.
