You have 1 article left to read this month before you need to register a free LeadDev.com account.
Pull request size massively impacts cycle time and development workflow – small PRs and low rework rates boost efficiency, stability, and lower overall risk.
The DevOps Research and Assessment (DORA) program gave development teams some great metrics to guide them on their journey from average to elite performance. But they’re only one piece of the puzzle.
Make no mistake, tracking DORA metrics are important and useful – just not for everything that an engineering team strives to do, such as showing how developers directly impact the business bottom line. That’s why most elite engineering organizations use a new generation of metrics and benchmarks to assess their impact.
Based on a study of nearly 2,000 developer teams and 847,000 code branches, these benchmarks inform what the top 10% of elite dev teams look like.
What’s clear from this study is elite development workflows start and end with small pull request (PR) sizes. This is the best indicator of simpler merges, enhanced CI/CD, and faster cycle times. In short, PR size affects all other metrics.
Combine this with rework rate and deployment frequency, and you get a crucial indicator of development workflow health and developer experience. Of these measures though, PR size presents the most significant opportunity for real organizational change.
Luckily, it’s also concrete, measurable, and achievable. Elite dev teams make less than 105 code changes (including additions and removals). This appears to be the ideal amount of change for ease of review and safety to merge.
Because small PRs get picked up and reviewed fast, they lower cycle time and positively impact other DORA metrics. There are fewer hand-offs and less idle time. Production blow-ups are smaller and teams can recover more quickly.
Beyond efficiency and moving work through the development pipeline quickly, low PR pickup and review times also tell a good story about team chemistry. Teams that have a smooth code review process also tend to have better code quality.
How better PRs affect deployment frequency
If PR size represents the guts of a project, deployment frequency is the heart. Teams should always strive to plan and work in small, manageable, and quickly releasable chunks. Good scoping and planning nets out to smaller PR sizes, resulting in a team that is constantly merging and deploying. The more frequent the deployment, the better the organizational cadence and developer experience.
It’s important to note that elite deployment frequency is daily – and anything more than a week suggests the need for critical focus. Daily deployment of code indicates a stable, healthy continuous delivery pipeline, which can happen quite naturally with lower PR sizes.
Smaller PR sizes correlate with higher test coverage and more thorough reviews, which are both hallmarks of higher deployment frequency and code quality. This also reduces change failure rates (CFR). It’s also much easier to roll back and fix issues, helping to lower mean time to restore (MTTR). Cycle time is lower, customers are happy, and so are developers.
How better PRs affect reworking and refactoring
The concept of rework rate (or code churn) can sometimes be confusing. If a dev writes code, the code merges to the main “trunk,” or the release, and it’ll almost always be refactored in time.
People assume refactoring is bad, but refactoring 6-month-old or 12-month-old code is a good thing.
It’s important to distinguish between rework and refactoring, though. Refactoring is a process of making preexisting code more efficient. Rework is the bad kind – a repeating pattern in a poorly functioning process. Or the rework could be due to a quality problem; perhaps product or engineering aren’t aligned on objectives.
Strong refactoring (except on code that’s just been committed) is a healthy sign of a well-functioning team. Teams with lower PR sizes and rework rates and higher deployment frequency also have more time to focus on refactoring.
How these workflow metrics impact others
PR size, deployment frequency, and rework rates all affect development workflow – signaling its overall productivity and efficiency. Average (and even strong) dev teams can grow stronger by zeroing in on these key metrics. When they do, other metrics – like planning accuracy, CFR, and MTTR – often fall in line.
A crucial dimension of the Engineering Benchmarks study is that predictability stems from smaller PRs and shorter cycles. By looking at the key indicators, teams can foresee problems before they come up, and they have the time and space to plan for them. Instead of spending up to three cycles recovering, teams know exactly how long problem-solving will take – if those problems happen at all.
With proper focus and utilization, development workflow metrics can transform organizations. As useful as the DORA metrics are, dev teams’ overarching goal should be using better indicators to power them into the elite bracket with a supercharged development workflow.
You’re Invited: A 3-part Summer Workshop Series for Engineering Executives
Engineering executives, register now for LinearB’s 3-part workshop series designed to improve your team’s business outcomes. Learn the three essential steps used by elite software engineering organizations to decrease cycle time by 47% on average and deliver better results: Benchmark, Automate, and Improve.
Don’t miss this opportunity to take your team to the next level – save your seat today.
