Besides the obvious legal problems caused by your software engineers sumo wrestling in the office, or the increased snack budget, there are other traits you want to avoid that developers could inadvertently be taking on that is similar to the sport of sumo wrestling.
Most teams use a Git versioning control system, where the code review or pull request process is vital to a healthy repo. Most companies require at least one review before a merge, and for the Author to not be the Approver unless under unique circumstances (such as being the only one with a specialty or solo projects).
The issue arises when this process has little visibility from other members of the team, whether that’s other individual contributors, CTOs or team leads. Without visibility, accountability is next to impossible to enforce, processes can be inefficient, and bad habits continue until something goes drastically wrong. With this specific stage in the development process, the following problems can arise:
- Explicit or implicit agreements to “go easy” on each other’s code reviews
- Pairs or teams that frequently work together grow complicit in code reviews
- A high impact pull request is assigned to too junior of a developer
- Pull requests authored by tough reviewers get pushed out of priority, or other social pressures (warning, foul language post link)
Even the most well-meaning teams can have these happen. However, what does this have to do with sumo wrestlers?
In the book Freakonomics, Steven Levitt and Stephen Dubner cover match-fixing in sumo wrestling. The main focus was when a wrestler had nothing to lose by losing (aka their rank wouldn’t drop in the tournament), but the other wrestler had a lot to gain by winning, the loser of the match was almost always the one with little to lose. Essentially, they created agreements to benefit each other, with great impacts to the tournament as a whole. I won’t bore you with the details, but you can learn more here:
Similarly to Sumo, code reviews are easy to continue to game without visibility and analysis of trends, which is when the above problems come up. There's a lot to gain with little risk for those who want to participate in these type of agreements. This causes issues for the team and code base as a whole, particularly high performing engineers who want to be proud of the code they’re producing. Bugs and crashes go up, with little auditability and easy analysis.
Gitalytics built Pull Request Interactions dashboard within the same platform our customers see their Git analytics for this specific use. With it, leadership and engineers can see if the team is self-approving pull requests, if there are team members constantly approving each other’s work,
if there’s a lack of comments or fast approvals on large pull requests, or if pull requests from individuals are aging.
By digging deep into Gitalytics’ other pull request dashboards, leaders can delve further into details, such as author cycle time trends, or where there are senior-level reviews of pull requests from junior team members.
Ultimately, this visibility will see where bad habits are being formed, where there are process improvements, and ultimately build a smarter, faster, and less buggy merge strategy.
If you're not already using Gitalytics, contact us to learn more about how you can get the benefits of greater visibility and understanding of your software development process. Learn more at http://gitalytics.com.