Do you have developers that work privately, keep large amounts of work in progress, and deliver massive pull requests right at the end of a sprint? You may be dealing with code hoarders.
Do you use Git and Jira?
Take them to the Next Level with our Git-Jira integration
→ Try it For Free ←
For many, it may seem natural not to share work when it’s only just started. Programmers can sometimes wait until their work is done before they feel comfortable sharing the code. This may stem from a general fear of being judged for work in progress or from others stealing the work. Programmers may also withhold code to make it seem like their process is seamless and requires minimal effort. It could be a way to show off.
The problem for managers and the team’s overall health is that the more your devs hoard, the less they collaborate. It’s riskier for the entire project when members code in silos, and it’s infinitely harder to gauge if sprint targets will get hit if you have a group of hoarders unwilling to share giant pieces of code until it’s “perfect.”
What’s worse is that, once the large dump of code is submitted for review, a person needs to wade through everything – a sometimes overwhelming endeavor. This hoarding habit can lead to lower quality code for two main reasons:
- The submitter might not have thoroughly checked their work and/or didn’t get feedback early enough in the process to catch potential mistakes
- The reviewer might not have enough time or energy to go through such a large amount of code line by line, also leading to potentially missing mistakes or issues with the code.
How to Recognize A Code Hoarding Situation
A simple way to find a hoarder is to keep an eye out for large or infrequent commits. This is the typical way to see if someone is working privately (until they’ve finished their project). A manager would spot this trend in the Work Log report or the Review Workflow. Typically, they are Pull Requests that are pretty large and come late in a sprint or project cycle. Their size will normally take longer to review or get a lower level of review.
Another telltale sign of a hoarder is someone that isn’t receptive to feedback. They may have lower than average Receptiveness in the Submit Fundamentals. Since they are working in their own silo and submitting their code in large batches for review only once they’ve emotionally committed to it being “right,” they’re generally less likely to look at the feedback they are getting objectively.
How to Handle Hoarders
As a manager, it’s crucial to treat hoarders respectfully. This pattern is most likely to be recognized right before the end of a sprint (or just after), and your team members may be stressed or worn out. These hoarders have likely just delivered a massive chunk of code, so telling them they’re doing something wrong when they’ve just worked tirelessly to deliver will not go over well, so be sure you provide space and approach them with caution.
Try arranging an informal one-on-one with your hoarder and get them to talk about the latest project. Find out, from their perspective, what went well and what didn’t work. Be sure to recognize the achievement of their deliverable. During the conversation, work on the idea of team collaboration. Explain the pros of sharing work along the way and how it helps with code reviewing processes. The idea is to get the hoarder to see that taking smaller bites throughout the process helps put less stress on them and the reviewer and helps the process move faster while ensuring the quality of the underlying code.
Conclusion
The ultimate goal is to ensure that there are no hoarders on your team. To ensure that’s possible, it’s essential to get hoarders on-side and seek solutions that help them get more comfortable with sharing code sooner and more often.
Do you need Jira and Git to talk to each other? Download our Git-Jira integration app and manage your Git right from Jira! Find this and many more great Git-Jira plugins right on the Atlassian Marketplace. Find apps for Bitbucket, GitHub, Gitlab, and more!
