What Are Code Churn?
The percentage of recently written code that is rewritten, deleted, or substantially modified within a short time period. High churn can signal unclear requirements, rework, or technical debt.
2-minute setup • No credit card required
What it means
Code churn measures instability in your codebase by tracking how often newly written code gets changed again. The typical calculation looks at code written in the last 2-4 weeks and measures what percentage of those lines were modified or deleted. It's calculated from git history: additions, modifications, and deletions on files that were recently changed. A churn rate of 15-25% is normal for active development — some iteration is healthy and expected during code review and testing. Churn above 30-40% consistently may indicate problems: unclear requirements causing rework, poor initial design decisions, insufficient planning, or technical debt forcing constant refactoring. However, context matters: churn is naturally higher during exploratory/prototyping phases and lower during maintenance phases.
Why Code Churn matter
Code churn is an early warning system for engineering managers. Sustained high churn on a project often means the team is thrashing: building, tearing down, and rebuilding the same functionality. This wastes engineering time and demoralizes developers. Tracking churn per developer can also reveal onboarding issues (new team members churning more as they learn the codebase) or review culture problems (reviewers requesting extensive rewrites instead of catching issues earlier). For project planning, high churn on a feature indicates it's not as close to done as the ticket status suggests. Churn is most useful as a trend metric — a sudden spike deserves investigation.
How to measure
Calculate from git data: for a given time window (typically 2-3 weeks), identify all lines added. Then check how many of those lines were modified or deleted within the same window. Churn rate = (churned lines / total lines added) x 100. Most git analytics tools (Gitmore, GitClear, LinearB) calculate this automatically. You can also approximate it with git log: compare the sum of additions and deletions over a period — if deletions are consistently more than 50% of additions, churn is high. Measure per-repository and per-developer to find patterns.
Real-world example
A team building a new payments feature notices their churn rate jumped from 20% to 55% over two weeks. Investigation reveals the product spec changed twice during development, requiring significant rewrites of the API contract and database schema. The engineering manager works with the product manager to freeze the spec and document edge cases before the team resumes coding. Churn drops back to 18% in the following sprint, and the feature ships on the revised timeline.
Related terms
Common questions
Is high code churn always bad?
No. High churn is normal during prototyping, major refactoring, or early exploration of a new architecture. It becomes a problem when it's sustained on features that should be stabilizing, or when it's caused by unclear requirements forcing repeated rewrites. Context matters — a 40% churn rate during a planned refactor is fine; the same rate on a feature that was supposed to ship last week is a red flag.
How is code churn different from code complexity?
Churn measures how often code changes; complexity measures how difficult code is to understand and maintain. They're related but distinct: high-churn code may or may not be complex, and complex code may or may not churn frequently. Files that are both high-churn and high-complexity are the highest risk areas in your codebase.
What is a normal code churn rate?
15-25% is typical for teams in active development. Below 10% might indicate the codebase isn't being actively improved or that developers are afraid to refactor. Above 35% consistently suggests rework problems. The ideal rate depends on the project phase: higher during early development, lower as features stabilize.
Can you measure code churn from Git?
Yes. Git tracks every addition, modification, and deletion. You can use git log with --stat or --numstat flags to get line-level change data, then calculate what percentage of recently added lines were subsequently modified or deleted. Tools like Gitmore automate this calculation and present it as a trend over time.
Track Code Churn Automatically
Gitmore turns your git activity into automated reports with real metrics — delivered to Slack and email.
Get Started FreeNo credit card • No sales call • Reports in 2 minutes