If you know even a little about me, you'd know I enjoy playing around with data, and I've been immersed in it lately. Lately, I've taken a liking to the "time-to-merge" metric.
In simple terms, the timer starts when a pull request is opened and stops when it's merged. Like many metrics in software engineering, it doesn't give the full picture. It's not the ultimate answer, but it's led me to some intriguing findings.
What Can This Metric Get You?
I'll say it once more: it's not the holy grail. But what you can gain is a valuable insight into how your team operates.
Some engineers may quickly push PRs through, while others take a bit more time. Interestingly, it's with the lengthier ones that I've seen the most benefits, especially when applying the lessons from the quick time-to-merge PRs.
A Quick Time-to-Merge PR
Looking at some of the fastest-to-merge PRs (excluding "emergencies"), a few reasons stand out for their speed:
- They were straightforward.
- Even if somewhat complex, they were well-documented and divided into easily digestible parts.
- They had a cohesive team behind them.
Discussing the third reason is a bit complex for this article, so I'll hone in on the first two. These points present significant opportunities for engineering teams to enhance their performance. Most sizable engineering teams probably have several members who could benefit from these insights.
The Advice
So, what's the takeaway? It boils down to simplicity and task segmentation. Wondering if a PR can be made less risky by shipping the migration separately first? Most likely. For instance, if you're adding a new column for a feature, and this column requires a backfilling script, consider:
- A PR just for the migration.
- A separate PR for the backfill script to run.
- Lastly, a PR dedicated to your new feature.
Now, you might ask, "Isn't this an unnecessary division?" From my perspective, it isn't. For instance, PR #1 might only involve 20-30 lines of code. When isolated from the broader task, it's straightforward: "Ah, a new column—approved!"
For PR #2, assuming it's a manually executed job for production, it might span 30-50 lines. Separating it out clarifies its purpose, making it simpler for the team to comprehend and approve.
Lastly, the feature PR. This might consist of several methods and tests, say around 150 lines. These 150 lines are much more digestible than 230 lines bundled together. Moreover, shipping these 150 lines becomes safer. With the database column in place and data already backfilled, all that's left is activation.
Negatives?
No approach is flawless. With this philosophy, you'll undoubtedly encounter individuals who either overextend its application or those who outright ignore the advice.
Both situations demand coaching and the promotion of best practices. The silver lining? The previous method (one large PR) isn't terrible—it just leaves room for improvement.
Takeaway's From This Article
Encouraging engineering teams to submit smaller PRs or to segment their work can lead to faster reviews and a more secure development process.
Using time-to-merge as an indicator for your organization is a good starting place. Observe the engineers with the longest durations, and I'd wager they're handling sizable, intricate tasks. For the sake of both safety and efficiency, aim to reduce that time.
